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® Manipulating rights-to-execute In connection with a software copy protection mechanism. 



® A software asset protection mechanism segre- 
gates the right to execute software from the software 
itself. The rights to execute, when installed on a 
composite computing system. (10,20) are stored in a 
coprocessor element (20) of the composite comput- 
ing system. The software asset protection mecha- 
nism is enhanced as described herein by providing 
for the manipulation of those rights to execute. More 
particulariy, the rights to execute can be conditioned 
at least In terms of a valid period of execution or a 
valid number of executions. The rights to execute 
can be safely transfen^ed from one coprocessor to 
^another, or can be returned to the software vendor. 
^Rnally, a method of backing up the rights to execute 
O)to provide the user with the rights to execute in case 
CO the coprocessor element of the composite comput- 
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MANIPULATING R1GHTS*T0*EXECUTE IN CONNECTION VITITH A SOFTWARE COPY PROTECTION MECHA- 
NISM 



Technical Reld 

The invention Is in the field of data processing, 
especially in connection with a software copy pro- 
tection mechanism. That mechanism restricts soft* 
ware, distributed on a magnetic disk or other me- 
dium, for use on any computer which is associated 
with an authorized, physically secure coprocessor 
where the mechanism does not Interfere with the 
user creation of "backup" copies,* but the protec- 
tion is not compromised by any such "backup" 
copies. The present invention is particularly di- 
rected at manipulating a right-to-execute which is a 
distinguishing characteristic of that copy protection 
mechanism. 



Background of the Invention 

The basic copy protection mechanism is de- 
scribed in copending application tYO985-09l]; this 
mechanism separates the software which is to be 
protected from the right to execute that software. 
To provide security and implement the mechanism, 
each computer on which a protected application is 
to run (hereinafter refen^ed to as a host) is asso- 
ciated with a logically and physically secure 
coprocessor. When installed in the coprocessor, 
the right-to-execute a particular protected applica- 
tion exists In the form of a software decryption key 
called an application key (AK). So long as the 
software decryption key AK is retained In the per- 
manent memory of the coprocessor, the conre- 
spondlng protected software can be executed on 
the composite system including the host and 
coprocessor. The software copy protection mecha- 
nism has the advantage that it negligibly interferes 
with present and contemplated software distribution 
techniques. It allows the user to make unlimited 
numbers of "backup" copies and it does not re- 
quire any two-way communication between the 
user and tiie software vendor. This is supported by 
distribution of an authorization to the coprocessor 
to accept a right to execute provided in the form of 
a hardware cartridge (or token). Furthermore, the 
user need only employ tiie token tiie first time tiie 
protected application is run in order to transfer the 
right to execute, which is represented by the un- 
used token, to tiie coprocessor. Thereafter, the 
token may be discarded and it is thereafter totally 
unnecessary to maintenance or use of the right to 
execute. 

The Invention described in copending applica- 



tion [YO985-091] does not address manipulation of 
tiie right to execute (ottter than describing how a 
user may first acquire it), nor does it describe the 
possibility of conditioning the right to execute. The 

5 present invention Is particularly directed at con- 
ditioning or manipulating or transfening ttie right to 
execute which exists in a coprocessor. 

In particular, tiie present invention provides the 
capability of safely transfemng the right to execute. 

70 The right to execute may be transferred to anottier 
coprocessor or may be merely transfeaed outside 
the coprocessor for external storage. In either event 
it is essential that tiie process of transferring the 
right to execute not generate or allow spurious or 

75 duplicate rights to execute which would of course 
defeat the purpose of the copy protection mecha- 
nism. As described herein, the transfer of a right to 
execute can be indirect, tiirough the use of a 
transfer set (which in many respects is identical to 

20 tiie distribution set tiirough which the right to ex- 
ecute was acquired) or direct via a coprocessor to 
coprocessor communication link. Safety is main- 
tained even tiiough the communication is unse- 
cured In the sense that the transfer transaction may 

2S be observed. 

The present invention also provides techniques 
for conditioning the right to execute. For example, 
the right to execute might be conditioned by a time 
period (a right to execute which exists up until a 
• 30 cut-off date and/or time) or it could be conditioned 
based on the number of times it is invoked (for 
example the vendor could sell a user the right to 
execute tiie protected application ten times). As will . 
be described, the right to execute can be con- 

35 ditioned on any other parameter so long as It can 
be measured by the coprocessor to the satisfaction 
of tiie source of ttiat right to execute (tiie software 
vendor). The availability of conditioned rights to 
execute provides the software vendor with addi- 

40 tional flexibility and it furttier opens up the possibil- 
ity, for tiie first time in tiie software field, of a truly 
safe "return" policy. For obvious reasons, a soft- 
ware vendor, using today's software distribution 
techniques, will be in Jeopardy of giving his pro- ^ 

45 ducts away free if he accepts the "return" of soft- 
ware for full purchase credit. The vendor has no *§ 
way of verifying witii present distribution tech- 
niques whetiier or not ttie user has already du- 
plicated tiie software so tiiat after the return the 

50 user could still maintain a fully usable copy of the 
application. Using the principles described herein, 
however, the software vendor can implement a 
"return" policy and be assured that if a user re- 
turns the software, the user no longer retains an 
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executable copy. 

Because the software copy protection mecha- 
nism operates in the real wortd. with real world 
devices, and because the distinct right to execute 
exists in the fomi of a cryptographic key stored in 
the permanent memory of a coprocessor, it is 
necessary to address the possibility that the 
coprocessor storing the right to execute may fail. 
Such failure should not result in the complete loss 
of the user's rights to execute, and the present 
invention provides apparatus and methods for se- 
curing the user against the loss of the right to 
execute in the event his coprocessor does fail. 
Much as in the case with moving or transferring the 
right to execute, any hardware "backup" technique 
(available in case a coprocessor ifaiis) should not 
have the property of being useful to generate spur- 
ious rights to execute. The hardware backup meth- 
od provides minimal opportunity (and significant 
disincentive) for improperiy multiplying rights to 
execute. 



Summary of the Invention 

The invention meets these and other objects as 
described below. 

Conditioned Right-to-Execute 

In order to condition the right to execute. In a 
system such as described in our copending ap- 
plication [YO985-091]. there must be: 

1) a statement of the condition (or condi- 
tions) under which the application software may (or 
may not) be allowed to execute fully, and 

2) some objective criteria against which the 
condition or conditions can be measured, and . 

3) a software program which can test the 
conditions against the criteria and act in a way 
determined by results of that test 

These objectives must be met in a way which 
cs secure against attempts of the user, or anyone 
else not specifically authorized by the software 
vendor to either vary the conditions or the objective 
criteria under which the conditions are met. In 
accordance with the invention, the criteria are stat- 
ed in software, and more particularly, in the pro- 
tected or encrypted portion of the application soft- 
ware. As is described in our copending application 
[YO985-091], the only form in which the protected 
application software is available to the user is in 
encrypted form; t)ecause the user does not have 
access to the decryption key as a data object, he 
is unable to modify, or even read the protected 
software. Thus, incorporating the conditions of the 
right to execute within the protected software re- 
sults in securing these conditions against alteration 
by the user or anyone else unless authorized by 
the software vendor. In order to save (for testing) 



the conditions which are tested against the pro- 
grammed criteria, we use some storage spac» in 
the non volatile memory of the coprocessor, this 
storage space has already alkx:ated to It the func- 

5 tion of storing the decryption key necessary to 
decrypt the encrypted software. Thus the storage 
space allocated to a particular protected piece of 
software Is expanded to include the condition which 
can be measured against the criteria. Because of 

70 the non-volatility of the memory, so long as the 
right to execute is available in the coprocessor, the 
objective conditions are also available. It shoukj be 
understood that the coprocessor contains a con- 
tinuously powered real-time clock witiiin its phys- 

75 icaily secure boundary so that in the case that 
criteria involving time are to be used, the time 
information is available. Because the information is 
stored in a coprocessor's non-volatile memory, and 
only the portion of this memory allocated to any 

20 particular application can be accessed by tiiat ap- 
plication, the information is secure against any at- 
tempt at modification by the user. The application 
software may modify the conditions stored in Its 
portion of non-volatile memory, but may not 

25 change the value of tiie real-time dock. 

For example, tiie software ttius could count the 
number of times or4he total period it had been 
used by changing numbers kept in this storage and 
executing only until criteria related to number or 

30 total period of executions were no longer met by 
the stored conditions. 

As an example, assume tiiat the software ven- 
dor has transferred to the user the right to execute 
on the condition that a certain terminal date had 

3$ not passed, (i.e. the user has the right to execute 
tiie protected application up to, but not after March 
1. 1987). The coprocessor's operating instructions 
necessarily, therefore, provide for storage of a last 
allowed use (terminal) date along witii the software 

40 decryption key. Since tiie coprocessor maintains a 
real time clock, whenever tiie decryption key is 
accessed or at intervals during application execu- 
tion, the terminal date and the cun^nt date are 
available. The terminal date provision is protected 

45 against unauthorized alteration by the security of 
tiie coprocessor as is the real time clock setting. 
The encrypted portion of tfie software (the pro- 
tected portion) describes the criterium tiiat execu- 
tion Is not available beyond tiie terminal date. 

50 Whenever the protected software is run, tiie de- 
cryption key and the terminal date are accessed 
from tiie coprocessor's non-volatile memory. The 
criterion tested In the protected software requires 
tiiat the terminal date be compared to tiie current 

55 date; if the cun^ent date is beyond the terminal 
date, tiien execution of the protected software does 
not proceed. The protected software can also be 
anranged to provide for deleting tiie particular soft- 
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ware decryption key In tiie event that the current 
date is beyond the temr^inal date. It should be 
apparent to those skilled in the art that another 
condition which can be substituted for the tennlnal 
date condition Is the number of times the software 
is executed. For this case, the protected software 
describes the number of executions which have 
been authorized, and in lieu of storing the current 
date along with the software decryption key, a 
count of allowed uses is stored which is decremen- 
ted each time the software is executed The pro- 
tected portion then tests the allowed number of 
executions against the criterion that the number is 
greater than zero. It then either decrements the 
number or, if the number of authorized executions 
is zero, denies the. user's request to execute the 
software (and perhaps the software decryption key 
is also deleted). It should be apparent that there 
are many variations to these specific implementa- 
tions, including elapsed time, passwords, and com- 
binations of these and other measurables, all of 
which are within the scope of the invention. 



Transfer of Rlght-to-Execute . 

Transferring the right to execute from one user 
to another (or more particularly, from a source 
coprocessor to a sink coprocessor) can be accom- 
plished by reconstructing a distribution set This 
procedure returns the right to execute to a portable 
form which is substantially identical to that from 
which it was acquired in the first place, see copen- 
ding application [YO985-091]. This procedure, nec- 
essarily, removes the right to execute from the 
source coprocessor. 

This transaction requires that the user obtain 
either a token or a disk and a token pair (also 
referred to as a Transfer Set), depending on the 
structure of the token. These sets can be provided 
by the hardware vendor. The token (or cartridge) in 
the set is loaded by the coprocessor hardware 
manufacturer. The Transfer Set, prior to manipula- 
tion by the user has a single piece of information, 
token data, stored in two forms. The token is load- 
ed, by the hardware vendor with clear text token 
data; tiie physical characteristics of the token pro- 
tect this sensitive infonmation from unauthorized 
persons. The same data is encrypted under a 
hardware manufacturer secret key called a Com- 
mon Supervisor Key (CSK) to generate EcsK{token 
data). It Is stored either on the disk of the Transfer 
Set or in the token if It is so structured as to allow 
it. Because EcsK(token data) is encrypM, it may. 
be stored on the disk even though in that form it 
can be read and even copied by anyone. It is 
necessary that the transfer set be prepared by a 
trusted source, such as a hardware vendor, be- 



cause if the token contents are known, other tokens 
could be loaded with known contents and the trans- 
ferred right to execute replicated. Assuming that 
the user has acquired a suitable transfer set the 
5 distribution set is prepared using a Reconstruct 
Distribution Set (RDS) process, by the user and his 
composite computing system, for example, as fol- 
lows. 

A utility program, running on the host com- 

70 puter, signals the (source) coprocessor that an 
RDS sequence is about to begin. The utility pro- 
gram identifies to the coprocessor the location of 
the key to be transferred. The coprocessor ex- 
ecutes a CBS (Create Backup Set) procedure on all 

75 allowed keys except the indexed key. The CBS 
procedure is described below. At tiiis point it is 
sufficient to note that the CBS procedure invali- 
dates any existing hardware backup mechanism. 
The coprocessor requests and receives a copy of 

20 the encrypted token descriptor EcsK(token data) 
from the transfer set The coprocessor decrypts the 
token descriptor to provide clear text token data. 
This clear text token data is then encrypted using 
the software decryption key identified by the index 

25 to produce EAK(token data). The coprocessor then 
stores this encrypted token descriptor E AK(token 
data) in a reserved non-volatile storage area of the 
token or on the disk and either erases or otherwise 
de-activates the software decryption key AK at the 

30 given storage location. The coprocessor then 
passes tiie encrypted token descriptor to the host 
for storage on the transfer set disk. As will be 
described later, the key (AK) to be transferred may 
be associated with conditions of execution. If these 

35 conditions of execution are unchanging (such as 
terminal date) tiien tiie encrypted application key 
may be copied to the transfer set disk. If the 
conditions of execution are changing (such as re- 
maining hours of use or remaining number of 

40 uses), tiien the encrypted file containing the ap- 
plication key and the conditions of execution can- 
not be copied from the distribution disk without 
resetting the conditions. This synchn^nization of a 
token descriptor file and an application key file can 

45 be achieved by including a correspondence test 
number in each file. The next step in transfer is 
tiius tiie preparation of an encrypted application 
key file for storage on the transfer disk. This prep- 
aration is identical to the encrypt vendor key 

so (EVK) transaction described below save that the 
conrespondence test number is substituted for the 
random number. This correspondence number 
could be a fraction of the token data After tills 
preparation and transfer, tiie utility program, run- 

55 ning in the host, tiien transfers to the ti^sfer set 
disk the two files containing the plain text and 
cipher text parts of the protected program. The 
reader can now verify that the distribution set is 
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identical to the distribution set d8scnt>ed In EP*A- 
. — [YO985-091] in that It Includes the encrypted 
token data, encrypted with the software decryption 
key AK. the plain text file and the protected or 
encrypted software file, also encrypted under the 
software decryption key AK, as well as the software 
decryption key AK encrypted by the hardware ven- 
dor's key CSK. The latter three elements n^ay be 
copied from the original distribution disk or any 
backup copy of those files If permitted by execu- 
tion conditions. It should be self-evident that since 
the distribution set is now identical in all but one 
respect, it is usable with any coprocessor to trans- 
fer the right to execute the particular encrypted 
software file. The only difference between the dis- 
tribution set and the originaT set from which the 
right to execute was acquired, is that the token 
data is very likely to be different this is immaterial 
as long as both portions of the set (the token 
cartridge and the diskette) have been derived from 
identical token data. The (source) coprocessor now 
deletes the decryption key AK from its temporary 
memory. At this point, the right to execute has 
been deleted from the source coprocessor and 
exists solely in the Transfer Set. 

Transfer of the right to execute, however, need 
not be indirect. e.g. through the transfer set already 
refenred to. Transfer of the right to execute can be 
direct, e.g. using a coprocessor to coprocessor 
communication link. Furthermore, the coprocessor 
^to coprocessor communication link need not be 
secure in order to maintain the safety of the right.to 
execute being transferred; rather the safety is cryp- 
tographlcally secured as will now be described. In 
the following discussion we will refer to a transfer 
from coprocessor to coprocessor, however, the 
reader should understand that the communication 
link between coprocessors can either be through 
direct connection, or can be through any bidirec- 
tional data communication system. A transfer of a 
right to execute from one coprocessor to another is 
considered safe when the two coprocessors in- 
volved are able to identify one another as 
"memt)ers of the family" and generate a one time 
only Session Key for their use in that transaction. 
The identification as memlDers of the family is 
needed for assurance that the procedures used by 
each will mesh correctly, so that proliferation of 
rights to execute will not occur, an so that other 
protected information will not be revealed. 

The transaction in which the Session Key is 
generated relies on the presence of information In 
high privilege memory which is common to the two 
coprocessor systems participating in the transac- 
tion and on the ability of coprocessors to generate 
good random numbers. The process which gen- 
erates a Session Key will result in both coproces- 
sors involved in the transaction possessing the 



same key only if both coprocessors have the nec- 
essary antecedent information in common. 

The transaction for mutual identification and 
generation of a Session Key is as follows. For 

5 purposes of this description we will refer to the 
user or the uSer*s composite computing system or 
the user's coprocessor as the source user, source 
composite computing system or source coproces- 
sor if the right to execute Is being transferred from 

70 that user, composite computing system or 
coprocessor. We will refer to the user, composite 
computing system or coprocessor as the sink user, 
sink composite computing system or sink 
coprocessor if the right to execute Is being trans- 

T5 ferred thereto. The source user signals the source 
coprocessor that a Session Key is needed. The 
source coprocessor generates a random number 
which will be used in generating the session key. 
pads it with another random string of bits, and 

20 appends a Message Authentication Code (MAC). 
The MAC can k>e used to ensure that the plain text 
message which Is recovered on decryption is iden- 
tical to the one transmitted. The source coproces- 
sor then encrypts the number with a key CSK and 

25 sends the encrypted numt)er to the sink coproces- 
sor. The sink coprocessor has performed the same 
function and has sent its random encrypted num- 
ber to the source coprocessor. The source 
coprocessor decrypts the numt>er received under 

30 the encryption key (CSK). In the event that each 
coprocessor stores multiple CSKs. then each 
coprocessor decrypts the received number under 
each CSK in succession until either a valid MAC is 
obtained, or the collection of supervisor keys 

35 (CSK) is exhausted. If a valid MAC is not found, 
tiien an enror message is returned. This will be the 
typical outcome if a processor which is not a 
"memt)er of the family" tries to pass itself off as 
one. If a valid MAC is obtained, then the random 

40 numbers generated in the two coprocessors are 
combined in both coprocessors and are used as 
the Session Key. Of course, part of the operating 
instructions for the coprocessors will define, a 
priori, the particular manner in which the random 

45 numbers are to be combined in order to generate 
the Session Key; one number could be concat- 
enated witii another; the numbers could be 
EXCLUSIVE-OR'ed, etc. 

In order to avoid the procedure which may 

50 require successive decryptions in a search for the 
"correct" supervisor key,- location information such 
as an Index for the supervisor key which had been 
used could be sent along wrtii the encrypted num- 
ber. There is an advantage, however, to the tech- 

55 nique which requires coprocessors to "search" for 
the correct supervisor key. A procedure which 
transmits an index number along with the encryp- 
ted number provides a growing collection of in- 
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formation about the supervisor keys to any ob- 
server. 

Once the Session Key has been generated, it 
is possible for the coprocessors to transfer rights to 
execute by encrypting them under the Session 
Key. The coprocessors' firmware, controlling the 
procedure, ensures tiiat the rights are erased from 
the source processor. The right to execute could 
be erased when transmitted by the source proces- 
sor, although a preferable technique is to erase the 
right to execute (the software key) only when the 
sink coprocessor indicates that the right to execute 
has been safety received and to activate the right 
to execute only when the source coprocessor In- 
dicates the right to execute has been deactivated. 
The right to execute, which is transferred in en- 
crypted form, is secured against an observer by its 
encryption and there is no need to employ a se- 
cure communication link or channel. 

Direct or inter-coprocessor communication is 
the method of choice for movement of rights to 
execute in a network or a mainframe link environ- 
ment In these cases or others involving placing 
more than one right to a particular application in a 
particular coprocessor, a count of the rights for a 
given package Is maintained in the key storage 
area of the source coprocessor so that the number 
of rights which have been received limits the num- 
ber which are distributed. 

It should be clear from the above descriptions 
that it is within the realm of this mechanism to 
associate with an AK a description pf the life span 
of an AK in several dimensions ( time, numbers of 
use. etc.). It should also be clear that it is within the 
capacity of this mechanism to divide or parcel out 
this span under control of software provided by the 
software vendor and executed by a coprocessor. 
Ubraries of software could be maintained in distrib- 
uted computing systems by these means without 
violating the conservation of rights to execute while 
providing benefit to the distributed computing sys- 
tem's user. 

In the event that a transfer of multiple rights to 
execute is required, the coprocessor to coproces- 
sor transfer proceeds as follows once a Session 
Key has been created. The source user Identifies 
to the source coprocessor those rights to execute 
(AKs) to be transferred. The source coprocessor 
executes a CBS procedure (defined hereinafter) in 
order to update any backup set of rights to ex- 
ecute. The source coprocessor then encrypts the 
software keys under the Session Key and stores 
them with the Session Key in a reserved location of 
temporary memory. The source coprocessor marks 
each software key from the key store (permanent 
memory) as inactive and sends tiie encrypted in- 
formation to the sink coprocessor. The sink 
coprocessor receives the collection of encrypted 



keys from the source coprocessor, and decrypts 
them under the Session Key. The sink coprocessor 
then stores the decrypted keys In its key store 
(permanent memory) marking them inactive and 

5 sends its host computer location information by 
which the applications can access the keys In the 
load decrypt run procedure. The files actually com- 
prising the protected software can be sent by any. 
conventional (unprotected) technique or apparatus. 

70 The sink coprocessor can return a message to the 
source coprocessor indicating receipt of the par- 
ticular software key or keys to induce the source 
coprocessor to eliminate those software keys from 
Its temporary memory. When tiie source coproces- 

76 sor confirms the removal, ttie keys are then ac- 
tivated by the sink coprocessor. 

It should be noted tiiat a software vendor may 
not wish to allow- transfer of a right to execute and 
that tills constitutes a temn or condition of sale. 

20 Conditions which control the allowed movement of 
rights to execute can be stored in association witii 
_M AK as part of the procedure in which it Is 
acquired. If a manipulation of an AK is requested 
by a user, then these conditions (flags) are tested 

25 against go/no-go criteria stored in the coprocessor 
firmware which implements the requested manipu- 
lation. 



30 Backup of Right-to-Execute 

The backup procedure to be described is one 
which is intended to insure that the collection of 
rights to execute stored in a user's coprocessor are 

35 not lost due to an unforeseen failure of, for exam- 
ple, tiie supply of power to the coprocessor's non- 
volatile memory. This is to be distinguished from 
backup procedures which are applied to files of 
data and software. The latter procedures are en- 

40 tirely -conventional, well understood, and are ap- 
plicable to those kinds of objects, where they exist, 
in this system (plain text and encrypted software 
and encrypted application key). Many functional 
copies of such objects may be kept for use by any 

45 authorized system, tiius ensuring against their loss. 
It is, rather, the objective of tiie backup procedure 
described below to back up rights to execute so 
that they are not lost but so that many functional 
copies of that kind of object cannot be made. 

50 Because the backup procedure is designed to 
circumvent the results of an unforeseen failure in 
the coprocessor, the backup procedure must cre- 
ate, external to the coprocessor, sufficient informa- 
tion so that the right to execute can be installed 

55 entirely independentiy of ttie (source) processor 
which stores an entirely valid right to execute. 
Because of this necessary Independence, the t>ac- 
kup procedure itself is a potential source of a 
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(duplicate or spurious) right to execute. Allowing 
the creation of backup rights is a policy decision 
for the software vendor. It is a potential detriment 
to his security and would be provided for his cus- 
tomers* convenience. As noted eariier with respect 
to transfers of rights, a provider of software may 
not wish to allow backup. This condition of sale is 
enforceable by the same mechanism as described 
for control of transfer given the existence of a no- 
backup flag associated with an AK. This option is 
desirable in tiie case tiiat the conditions of execu- 
tion may change. To minimize the impact of bac- 
kup rights, they are. in this system, made con- 
ditional in that they expire after a . conveniently 
short interval which is long enough for the user 
who has actually had a failure in his coprocessor to 
have tiiat failure verified, for example by the hard- 
ware; manufacturer. 

Assuming tiie hardware manufacturer verifies 
the failure of the user's coprocessor, the means are 
provided to the user to carry out an additional 
procedure to remove the condition on the backup 
rights. In order to safely integrate the creation of 
backup rights with the other capabilities described 
herein, the creation of backup rights should l9e 
thought of as beginning a transfer of all allowed 
rights which is then left pending completion. Trans- 
fer procedures are necessarily interrelated witii the 
backup procedures so tiiat any user backup set 
(which carries a potential right to execute) is invali- 
dated at the time any complete transfer is effected. 
This prevents the transferred rights from also fc)6ing 
present in a valid backup. Accordingly, the user 
has tiie following options in connection with the 
procedures descril^ed herein: 

1. With his right to execute installed on a 
coprocessor, the user can have a backup set 
(representing a collection of potential rights to ex- 
ecute) which can be converted Into an actual, but 
conditioned, right to execute, or 

2. The user can remove one or more rights 
to execute from his coprocessor and install them in 
a transfer set or directly transfer them to anotiier 
coprocessor, but that procedure requires invalida- 
tion of the existing backup set. This requirement is 
entirely consistent with the user's rights since when 
rights to execute are removed from a coprocessor, 
tiiere is no need for the rights to be represented in 
ttie backup set Obviously, a new backup set which 
correctly reflects the diminished set of installed 
rights to execute may be prepared Immediately 
after a transfer. 

The procedures arranged for creating backup 
rights are comprehensive in that a single backup 
set can retain potential rights to execute for mul- 
tiple applications. The procedures contemplate tiiat 
tiie user's collection of rights on execute may be 
dynamic. 6.g. his collection of rights on one day 



may be greater or less than his collection of rights 
on anotiier day. This necessarily requires that the 
backup rights be dynamic too and track changes in 
the user's collection of rights to execute. 

5 Basically, the backup procedure is a two-step 
process, in a first step a Backup Set is created 
(Create Backup Set. or CBS); tiie Backup Set in- 
cludes a disk on which an encrypted file of rights 
to execute (for a group of applications) is stored. A 

70 supervision key which is unique to this (source) 
proces^r (USK) is also included in tills file. This 
information will allow the hardware manufacturer to 
verify tiiat tiie failed processor which tiiey receive 
as evidence of the failure is tiie processor claimed 

16 to have contained these rights. A token which can 
validate this collection to a coprocessor is also part 
of the set. The key used to encrypt this file is a 
random number generated by the coprocessor, 
possibly by encrypting the date and time a 

20 unique supervisor key (USK). It is the authorization 
to use this random number (RK) key which Is 
validated by the backup set token. As noted atx)ve, 
tiie Backup Set is considered a pending transfer. 
The second step in the backup process is 

25 Install Backup Set (IBS): in this step the potential 
right(s) to execute represented by the backup set 
consisting of tiie token and disk, is installed on a 
coprocessor. Because it is contemplated tiiat tiie 
user is likely to execute tiie CBS step of tiie 

30 backup procedure on plural occasions before ever 
executing tiie IBS step, tiie token which is em- 
ployed in the Backup Set must be more capable 
than tiie token used in the Distribution Set tills 
capability is required because of the fact that tiie 

35 user may execute tiie CBS step each time a new 
application is acquired. The user's existing backup 
must be invalidated at that time to prevent the 
creation of additional rights to execute. Accord- 
ingly, the token data will typically be much longer 

40 than the token data used in a Distribution Set so 
that a portion of that token can be read as part of 
each CBS transaction, changing the token content 
as a consequence, and invalidating previous bac- 
kup disk files, without In the process completely di- 

45 scharging the token. The same token may then ,be 
used for the IBS transaction if tr when it is needed, 
it is presentiy contemplated that rather than em- 
ploying shift register storage on such a Backup Set 
token, storage will be designed around random 

50 access memory. The description which follows 
however will for simplicity assume that tiie backup 
token is based on shift registers as in copending 
application [YO986-010], but containing extra 
length shift registers. 

55 Prior to initiating a CBS step, the user has 
acquired a Backup Set consisting of a token and a 
disk. The disk, as acquired by tiie user, stores 
encrypted token data, Ecsxitoken data). The token. 
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as acx)uired, stores clear text token data 

The CBS step proceeds as follows: 

A utility program signals the coprocessor that a 
CBS sequence Is about to begin. 

The coprocessor requeste and is given the 
encrypted token data corresponding to the token 
portion of the Backup Set 

The coprocessor decrypts the token data and 
selects the amount of the token data that will be 
used. "Use" of a portion of the token data implies 
that this portion of the token data will be destroyed; 
the remaining portion of the token data is- available 
for subsequent executions of the CBS procedure, 
for example when the user obtains a subsequent 
application, the rights to which he desires to bac- 
kup. 

The coprocessor generates a random numt>er 
of length equak to ths^ amount of the token data to 
be used and employing the random number 
"reads" or challenges the token and obtains the 
token response^ Since the coprocessor already has 
available.to it:the clear text token data and the 
random number It has generated, it can predict or 
compute the con'ect response. The computed re- 
sponse and the actual response of the token are 
compared. If the comparison Indicates that the to- 
ken response and the computed response do not 
correspond, then an invalid token has been pre- 
sented, an error message Is retumed, and the 
sequence terminates. Assuming, however, that the 
computed and actual responses con-espond, then 
the transaction continues. By reading or challeng- 
ing the backup token, the token data contained 
therein is changed (as well as verified). Changing 
the token data invalidates ail copies of any pre- 
vious backup. Thus the necessity for the length of 
the token; it can only be used a number of times 
given by the ratio of the bit length of the token 
portion to the portion used each time the CBS step 
is executed. When the token contains only enough 
data for one more transaction, it may be read to be 
destroyed and a new backup token may be started. 

For the remainder of this transaction, it Is as- 
sumed that the cryptographic system employed In 
the coprocessor allows any number to be a valid 
key. Random numbers are tiius valid keys. This 
property is a characteristic of the DES system. 

l-laving verified the authenticity of the token, 
the coprocessor now encrypts, under a second 
random numt>er. the remaining, unused portion of 
the token data, the allowed portion of Its key store 
and the unique supervisor (USK) key which iden- 
tifies that source processor. The encrypted block, 
as described, then be stored on a disk. This 
file will be used for the Install Backup Set proce- 
dure. 

A copy of the random number used as an 
encryption key above is now encrypted under a 



supervisor key using the encrypt vendor key proce- 
dure. This datum is now stored on the backup disk. 

These files can be copied in tiie same way the 
protected software can be copied. I.e. an unlimited 

5 number of times. However, the file is usable only 
witfi the token and then only in the event the token 
has not been read in the interim. As already de- 
scribed, any subsequent transfer operations require 
Invalidating the token. The Install Backup Set step 

10 is now described, assuming that the user has ac- 
cess to botii tiie file that was created during tiie 
last execution of the CBS step, as well as the 
token, which has not been read In tiie interim. 
We also assume tiiat in tiie interim the user's 

75 coprocessor, tiie source coprocessor, has failed, 
but tiie user has available another (sink) coproces- 
sor. The Install Backup Set procedure will install, 
on ttie sink coprocessor all tiie rights to execute 
that had existed on the user's source coprocessor 

20 (to ttie extent backup was allowed). However, In 
order to protect the software vendors, the entire 
collection of rights to execute will be conditioned 
by a grace period. During the grace period, each of 
tiie rights to execute will be operative and the user 

25 can employ them as he would have in his (source) 
coprocessor. During the grace period, the user can 
return his failed (source) coprocessor to the hard- 
ware vendor. The hardware vendor, after verifying 
that the coprocessor has Indeed failed, will provide 

30 to the user a disk having an encrypted message 
verifying, to the (sink) coprocessor that tiie 
(source) coprocessor has failed so that tiie grace 
period condition on the rights to execute can be 
lifted. Accordingly, the IBS step includes two sub- 

35 steps; a first sub-step installs the rights to execute 
in tiie (sink) coprocessor. At tiie time tiiese rights 
to execute are installed, tiiey are conditioned so 
they become Ineffective at the expiration of a grace 
period. The second sub-step in the IBS step is 

40 removal of the condition on tiie rights to execute 
by employing a disk acquired from tiie hardware 
vendor. The IBS step then proceeds as follows. 

A utility program signals the sink coprocessor 
that an IBS sequence is about to begin. The 

45 coprocessor first requests, and is sent, the encryp- 
ted random number key which has been used to 
encrypt the backup file. This Is decrypted under 
the appropriate CSK. The coprocessor then re- 
quests and is given tyhe encrypted backup file. 

50 The encrypted backup file Includes the encrypted 
token data, the contents of the key store from the 
(source) coprocessor and the unique supervisor 
key of tiie source processor. 

The (sink) coprocessor decrypts the backup 

55 file using the random number key found in the 
previous step, removes the token data and verifies 
the token. Token verification proceeds as in ver- 
ification of tiie Distribution Set, i.e. tiie verification 
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changes the token contents. As a result, the token 
can be used to perfonn an IBS procedure only 
once. Assuming the token is valid, the set of bac- 
kup rights to execute is Installed in the permanent 
memory of the (sink) coprocessor, along with an 
expiration date, thus determining the extent of the 
grace period. 

A message is now prepared by the (sink) 
coprocessor containing a copy of both coproces- 
sors' unique keys. This message Is returned with 
the failed source coprocessor so that the condition- 
lifting message from the hardware vendor can be 
identified by the sink coprocessor as intended for 
It, and as intended for the set of rights to execute 
of the particular source coprocessor. 

At this point the (sink) coprocessor is In the 
same condition that the (source) coprocessor was 
at the time it was last backed up. except that ail the 
rights to execute are conditioned on the expiration 
date. Assuming that the user obtains, from the 
hardware vendor within the grace period, the ver- 
ification disk, the second sub-step of the IBS step 
proceeds as follows. 

A utility program signals the (sink) coprocessor 
that an IBS sequence is about to be completed. 
The (sink) coprocessor requests and receives the 
validation file and decrypts it under its supervisor 
key (the USK of the sink). If the file contains the 
unique key which identifies the (source) coproces- 
sor, then the condition is lifted. If the file does not 
contain the unique key of the (source) coprocessor, 
then an error message is retumed and the sub-step 
is not completed. 



Backup Through Inter-Processor Communication 

In the preceding, the "hardware" backup has 
been described as comprising the CBS and IBS 
procedures, both of which rely on an extended 
token. Use of a token or extended token however, 
is not essential to "hardware" backup, and an 
intermediate coprocessor can be employed In lieu 
of the token or extended token for "hardware" 
backup purposes so long as the intermediate 
coprocessor can be arranged to firstly commu- 
nicate with the source coprocessor (for the CBS 
procedure) and then communicate with a sink 
coprocessor (for the IBS procedure). 

The inter-processor' variant of the "hardware" 
backup procedure Is now described. 

For this description, we assume that the source 
coprocessor is in communication with the 
"intermediate" coprocessor. The coprocessors ini- 
tially exchange encrypted random numbers, each 
encrypted under a supervisor key selected by the 
transmitting coprocessor. As already described, 
each of the coprocessors can decrypt and recog- 



nize that it has decrypted the encrypted random 
number transmitted by the other coprocessor even 
though It is not initially aware of the specific su- 
pervisor key employed. Assuming that each of the 

5 receiving coprocessors successfully decrypts the 
encrypted random number, they both combine 
those clear text random numbers to generate the 
Session Key which will be used for subsequent 
communications. 

TO The source coprocessor then extracts the ap- 
plication key (AK) or keys sought to be backed up 
from, Its permanent memory and encrypts that key 
Infonfnation and Its USK under the Session Key to 
generate an encrypted key block. This Is stored on 

75 a backup disk. The Session Key is stored by the 
intermediate coprocessor in its secure memory 
along with a descriptor indicating that the key cor- 
responds to a backup set At this point the inter- 
mediate coprocessor has possession of the key 

20 needed to access the AK or AKs which are being 
backed up and were it not a trusted recipient it 
could generate spurious rights to execute. How- 
ever, the Identification pnxedure refenred to above 
has identified, to the source coprocessor that the 

25 intenrtediste coprocessor is a "member of the fam- 
ily". As such a member of the family, the logical 
and physical security of the Intermediate coproces- 
sor protects the right(s) to execute which have 
been transfenred from spurious duplication or use. 

30 The actual encrypted application(s) can be trans- 
mitted to the intermediate coprocessor for the IBS 
procedure, by any conventional means. 

If at a subsequent time the source coprocessor 
is requested to transfer right(s) to execute which 

35 have been backed up via an "intermediate" 
coprocessor, as already described tiiat transaction 
cannot take place until tiie source coprocessor 
communicates with the "intennediate" coprocessor 
to Invalidate the backup rights. Such communica- 

40 tion has only three essential componente. The first 
component Is the identifier sequence as already 
described. This satisfies tiie source and intermedi- 
ate coprocessors tiiat the communicating parties 
are indeed "members of ttie family". The second 

45 component is tiie transmisston from the source 
coprocessor to the Intermediate coprocessor of a 
message requesting invalidation of the backup 
rights key. The third component is the reply from 
tiie intermediate coprocessor tiiat it is indeed tiie 

50 intermediate coprocessor which stored tiie backup 
rights and tiiat tiie righte have been invalidated. 

The backup rights stored In a "intermediate" 
coprocessor can either be installed, using an IBS 
procedure, in the Intermediate coprocessor, or can 

55 be installed in a different (sink) coprocessor. If ttie 
backup rights are to be installed in the intenmediate 
coprocessor, that action is readily effected by a 
user request through the host associated with tiie 
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intermediate coprocessor, the rights are installed 
without requiring a tolcen but. as already described, 
those rights are conditioned on the grace period. 

In the event that an IBS procedure using an 
intermediate processor is performed, the proces- 
sors: first establish their mutual identities as 
"members of the family" by estabfishing a session 
key. The random key may then be encrypted un- 
der the session key and transfenred to the sink 
coprocessor. The sink coprocessor is thus autho- 
rized to install the set of backup rights to execute 
with the grace period and prepares a message for 
the hardware manufacturer as previously de- 
scribed; 



Encrypt Vendor Key 

As described: both in this application as well as 
in copending EP-Ar [YO985-091]. the coproces- 
sor is also used: ta provide a service to a software 
vendor of encrypting the software decryption keys 
(AIQ. It Is essential ta the protection provided by 
the entire software copy protection system that the 
supervisor keys (CSK) which are used to encrypt 
the software vendor's decryption key be main- 
tained secret By allowing the software vendor the 
use of a coprocessor and the ability to encrypt an 
unlimited number of keys, the software vendor is in 
a position to mount a conventional "chosen plain 
text" attack on the hardware vendor's encryption 
keys (CSK). In the event that a software vendor 
were able to leam the hardware vendor's keys 
(CSK). that software vendor could use those keys 
in an attack on encrypted software of other soft- 
ware vendors. The "chosen plain text" attack re- 
quires that the attacker have access to sets of 
corresponding plain text and cipher text. Using 
these sets the attacker may attempt to Identify the 
key which will produce the cipher text from the 
plain text or visa versa The difficulty of doing this 
is, of course, dependent on the cryptographic sys- 
tem chosen and the computing power available to 
the backtracking task. Some cryptographic systems 
(such as DES) are extremely resistant to unlimited 
plain text attacks. 

In a first limitation on use of the coprocessor In 
a plain text attack, the coprocessor is anranged so 
that the software vendor requires authorization from 
the hardware manufacturer in order to create rights 
to execute. This authorization is sold, by the hard- 
ware vendor to the software vendor. Accordingly, 
one limitation on the software vendor's use of the 
coprocessor in a plain text attack is the economic 
cost expended in generating sets of plain text and 
con-esponding encrypted text. Another technique is 
the use of the following Encrypt Vendor Key (EVK) 
procedure. 



A utility program signals the coprocessor that 
an EVK sequence Is about to begin. The coproces- 

' sor requests and is given the key (AK) to be 
encrypted, typically a software vendor's key. The 

5 key is supplied by the software vendor along with 
desired settings of supervisor flags. These flags 
control whether or not the supervisor will allow (for 
example) backup or transfer of the associated key. 
The conditions of the execution which will be 

70 examined and/or changed by the application key 
are also supplied. It should be understood that in 
the following discussion AK refers to the entire 
datum (flags, key and conditions) to be prepared 
for transfer by this process. 

75 The coprocessor generates a random number 
(RN) and uses it to pad the front end of the key 
AK. The coprocessor pads the back end of the key 
with a recognition flag (RF). As previously de- 
scribed, the RF may be a MAC of any kind which 

20 is appropriate both to verifying that the con^ CSK 
has been used (during decryption) and to the cryp- 
tographic system employed by the coprocessor. 
Both the random number and the recognition flag 
are unknown to the user, e.g. the software vendor. 

25 The coprocessor encrypts the resulting block under 
a supervisor key (CSK) and passes the result back 
to the utility program. The result. Ecsk(RN^K.RF). 
where represents string concatenation, i.e.. 
01.111 produces the string 01111, can be decryp- 

30 ted by any coprocessor tiiat Is awaro of CSK. The 
result of such a decryption RN.AK.RF includes the 
three components, i.e.. a random number (RN), tine 
decryption key (AK), and a recognition flag (RF)- 
The decrypting coprocessor can always identify AK 

35 so long it has a priori access to the length of the 
suffix recognition flag. The random number pad- 
ding assures that even if the same key (AK) is 
submitted many times, tiie resulting blocks and the 
encrypted results will be different thus foiling the 

40 plain text attack. The EVK procedure has another 
advantage in that so long as the decrypting 
coprocessor has a priori knowledge of the recogni- 
tion flag (RF) It can decrypt tiie encrypted block 
without specific a priori knowledge of CSK so long 

45 as it has a priori knowledge of all possible CSKs. 
More particularly, assume that each coprocessor is 
provided by the hardware vendor with CSK1-CSK5. 
If appropriate measures are taken to avoid cryp- 
tanalytic attack one can further assume that the 

so recognition flag (RF) which is used is always the 
encryption key itself. These measures must in the 
case of block ciphers Include that the RN is not an 
Integral numtser of blocks in length. Furtiier assume 
that the encrypting coprocessor randomly selects 

55 CSKd witii which to encrypt a particular software 
key AK. Thus tiie encrypted bk>ck Is Ecsicr 
(RN.AK.CSK3). Any oWier coprocessor having ac- 
cess to CSK1-5 can corpectiy decrypt tills block 
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even though it is not aware which of the keys 
CSK1-5 have been used. It is only necessary for 
the coprocessor to decrypt the encrypted block 
with each of the keys CSK1-5. In only one instance 
will the plain text version include, as a suffix, the 
decryption key actually used. 



Virtual Key Storage 

In any practical Implementation of the software 
protection mechanism described herein and de- 
scribed in [Y098&091], there must be some limit 
to the ability of the coprocessor to store rights to 
execute. If a user obtains such a number of rights 
to execute greater than can be stored in the 
coprocessor, the user could convert seldom used 
rights to execute back to transportable form 
through the transfer transaction. The act of swap- 
ping AKs into and out of the coprocessor by these 
methods could easily prove burdensome to users 
and would be contrary to the spirit of this mecha- 
nism. It Is easy, however, given the resources of 
the coprocessor, to overcome this problem. 

In the simplest case, the AK represents the 
right to access the services of a piece of software. 
Extending this concept slightly, a Meta-AK (MAK) 
may be thought of as representing the right to 
access a collection of rights to execute. This sort of 
Key has already been seen in a limited form in the 
RK or random key used in the backup transaction. 

Assuming a user has filled all the key positions 
in his processor and wishes to install yet one more, 
the coprocessor can give the user the option of 
starting a file of keys on a system disk (hard or 
floppy). This collection of virtuallzed keys is stored 
in an encrypted form under a MAK. Each time the 
collection is accessed to move or add an AK. the 
collection is re-encrypted under a new random 
MAK. The MAK is stored in the key store and is 
merited as a MAK in the flags which control backup 
and transfer to facilitate its correct handling by the 
processor. The change of MAK on each access is 
needed to keep the virtuallzed key store which is 
used by the processor synchronized with the actual 
collection of rights to execute possessed by the 
user. Copies of old virtuallzed key stores which 

- contain transferred virtuallzed rights to execute 

cannot be foisted on the coprocessor because they 

^ will not decrypt correctly on loading. 

A specific procedure for creating virtuallzed 
keys (for the purpose of freeing up key storage) 
proceeds as follows. A utility program running on 
the host signals the coprocessor that the user has 
requested creation of a virtuallzed key. The 
coprocessor requests the user, via the host, to 
identify by location information, the AKs which 
should be included within the virtuallzed store. 



Based on the user identification, the AKs identified 
are extracted from the key store along with their 
flags (identifying authorization for transfer, backup, 
etc.), conditions of execution and location informa- 

5 tion. The coprocessor generates a random number 
and encrypts the block consisting of that data. The 
resulting encrypted block can now be written to 
disk (hard or floppy). The random number (the key 
to the virtuallzed store) is then written in the per- 

10 manent memory In place of one of the AKs which 
has been virtuallzed. A key reference path file 
which maps the virtuallzed keys to the random 
number MAK Index can be provided In plain text to 
an access utility on the host to allow reference 

75 ambiguity to be resolved. This file associates the 
random number key with the location information 
identifying the AKs which have been virtuallzed. If 
the user, at any later time, requires execution of 
software protected by one of the virtuallzed keys. 

20 the coprocessor first attempts to use the key at the 
referenced location. The con'ectness of the key 
found in that location can be tested by conventional 
message authentication techniques. This key ver- 
ification can be pisrformed by loading and decryp- 

25 ting a short message file with an authentication 
section (provided as part of the protected pro- 
gram). If on decryption the authentication is valid, 
the correct key has been found. If the authentica- 
tion is invalid then the access utility can provide a 

30 list of virtuallzed key access paths which will con- 
tain the key If the user indeed possesses that key. 
These keys are obtained by decryptirtg the vir- 
tuallzed block and extracting the appropriate AK. 
These keys may then be tested for validity by 

35 repeating the authentication procedure described 
above. At this point the coprocessor has access to 
the selected, previously virtuallzed AK. 

Clearly a virtualized key store could Itself con- 
tain MAKs so that the size of the key store can be 

40 extended indefinitely. 



Demonstration Software 

45 The virtualized storage technique also provides 
for supporting demonstration software without the 
need for any validating mechanism such as a token 
source or cartridge. The transaction proceeds as 
described below. The set of flags which allow or 

50 disallow transfer and backup of keys Includes a 
further flag which altows or disallows erasure of 
keys. If an AK is to be accepted in the absence of 
a token, then the data files for loading that AK 
include a null token descriptor so that the empty 

55 token connector will respond conrectly to the token 
query. The flag settings for this particular AK In- 
clude settings tiat allow it to be backed up and do 
not allow it to be moved or erased, installation of 
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such an AK also requires a search of both installed 
and virtual key stores to see if this key had been 
installed before. 

Conditions for executing demonstration soft- 
ware (preferably) include elapsed time or number 
of' uses.- An AK installation which proceeded under 
conditions as described above would allow a per- 
son to acquire the right to execute a piece of 
software for demonstration purposes, typically a 
one time use. A second attempt to install the 
identical AK would detect the prior acquisition, 
since the key store Is searched and tiie key cannot 
be moved or erased. The user is protected from 
ftlShg* his key store with useless demonstration 
keys by having them virtuallzed. The software ven- 
dor is protected from having his code reinstalled 
repeatedly, using demonstration software, without 
control. 



Brief Description of the Drawings 

The present invention will now be described in 
such detail as to enable those skilled in the art to 
practice the same in the following portions of the 
specification when taken In conjunction with the 
attached in which like reference charactecs identify 
icfentical apparatus and in which: 

Rg. 1 schematically Identifies the important 
components of the software asset protection 
mechanism and how they Interact; 

Rgs. 2-4 are similar to Rg. 1 buf are useful 
in explaining the use and application of conditioned 
rights-to-executa; 

Rgs. 5-7 are similar to Rg. 1 and are useful 
in explaining transfer of a right to execute; 

Rgs. 8-16 are similar to Rg. 1 and adapted 
to illustrate the two steps of the backup procedure, 
particulariy Create Backup Set (CBS) and Install 
Backup Set (IBS); 

Rg. 17 shows a typical time sequence in 
emptying tiie CBS and IBS procedures; 

Rg. 18 is useful in explaining tiie Encrypt 
Vendor Key (EVK) procedure; 

Rg. 19 is useful In explaining the appear- 
ance of a key store illustrating several features of 
the flags and conditions accompanying keys; and 

Rgs. 20 and 21 are useful in explaining a 
direct transfer of a right-to-execute. 



Detailed Description of Preferred Embodiments 

Reference has already been made to copen- 
ding application [YO985-091], the disclosure of 
which is incorporated by this reference along with 
YO986-010 (disclosing an example of a token). 
Application [YO985-091] discloses tiie basic soft- 



ware asset protection mechanism. That mechanism 
will be briefly reviewed in connection with Rg. 1. 
The software asset protection mechanism requires 
that the user employ a composite computing sys- 

5 torn Including a host 10 and a coprocessor 20. 
connected via some communication link or path 14. 
As described in [YO985-091], tiie patii 14 may be 
an internal bus, e.g. enclosed within the covers 
which encompass both tiie host 10 and the 

70 coprocessor 20. or the patii 14 can comprise a link 
between an I/O device included within the 
coprocessor 20 and an I/O device associated witii 
tiie host 10. Regardless of the specific nature of 
tiie link 14, tiie coprocessor 20 is provided with 

IS physical security which is effective to prevent me- 
chanical tampering or access to the interior of the 
coprocessor 20 by a user or a pirate. That physical 
security is represented in Rg. 1 by the interior 
dashed line boundary. Two important featores of 

20 the coprocessor 20 are its permanent, non-volatile 
memory 25 and a temporary memory 26; the latter 
akin to the working memory (RAM) of a conven- 
tional computer. The coprocessor 20 is provided to 
the user In a fomn In which it has at least one 

25 decryption key CSK stored in the permanent mem- 
ory 25; tiie decryption key CSK is provided and 
stored by the vendor of tiie coprocessor 20. In 
order tor the user to execute a protected appGca- 
tion, he must install a right to execute the applica* 

30 tion in the permanent memory 25; this right to 
execute is represented by a software decryption 
key AK. As described in the application [Y0985- 
091] the user, in order to instell the right-to-ex- 
ecute, receives from the software vendor a disti'ibu- 

35 tion set which includes a hardware cartridge 30 and 
a distribution disk 16. As shown in Rg. 1, the 
distribution disk 16 typically stores three files; of 
these files, one Is tiie protected application. Typi- 
cally the protected application will appear as two 

40 parts in two sub-files, a plain text application file A 
and an encrypted or protected portion application 
file B. As Rg. 1 shows tiie application file B is 
encrypted under tiie software decryption key AK. A 
second file on the distribution disk 16 is the soft- 

45 ware decryption key, encrypted under the key 
CSK. Rnally. the last file on the distribution disk is 
token date, Ti, encrypted under the software de- 
cryption key AK. As Is also explained in [Y0985- 
091], it is not essential that the third file be Incor- 

50 porated in the distribution disk 16 and alternatively 
it may be incorporated In the hardware cartridge 
30. 

The hardware cartridge stores tiie token data« 
Ti, in plain text form. Like the coprocessor 20, the 
55 hardware cartridge 30 is provided witii physical 
security. To install the right-to-execute, tiie hard- 
ware cartridge 30 is coupled to or linked to the 
combined computing system; Rg. 1 represente this 
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coupling via a connecting cable 18. The coproces* 
sor decrypts the software decryption key AK in 
temporary memory. Before accepting the software 
decryption key AK into permanent memory, the 
coprocessor 20 verifies that the hardware cartridge 
30 is authentic in a forgery-resistant 
query/response transaction (since its contents, Ti, 
correspond to the encrypted file Eak(Ti)). The hard- 
ware cartridge 30, t)ecause of its destructive read 
property, will only contain the token data, Ti, if it 
has not been used. After verifying that the hard- 
ware cartridge 30 is botii authentic and unused 
(and destroying the utility of the hardware cartridge 
in this process) the coprocessor will accept the 
right to execute, and store in its permanent mem- 
ory 25 ttie software decryption key AK. With ac- 
cess to tiie software decryption key AK. the pro- 
tected application file B can be decrypted and 
stored in the temporary memory 26 of tiie 
coprocessor 20 so that it may be executed by tiie 
coprocessor 20. Because of its physical and logical 
security, the plain text form, in which application 
file B is stored in temporary memory 26 during the 
course of execution and is not available to the user 
or a pirate. 



Conditioning Rights to Execute 

The software asset protection mechanism, as 
briefly described above, installs an unconditioned 
right to execute in the coprocessor' 20. However, it 
is one of the features of the Invention tiiat ttie right 
to execute can be conditioned, and examples of 
conditions are terminal dates and times, or num- 
bers of executions. Rg. 2 Is similar to Fig. 1 except 
that In ttie case of Rg. 2 tiie protected portion of 
tiie application file includes a criterion for execu- 
tion. e.g., if the terminal date and/or time is later 
tiian ttie present date then execution is allowed. On 
presentation of a distribution set as shown in Rg. 2 
to ttie combined processing system of the host 10 
and tiie coprocessor 20. tine Installation of tiie right 
to execute proceeds exactiy as was described in 
connection witii Rg. 1. The coprocessor 20, via ttie 
agency of the host 10. verifies (and destroys) the 
token 30 by comparing its plain text contents (Ti) 
with a decrypted version of the file Eak(Ti) read 
from the disk 16. On verifying the authenticity and 
ttie previously unused nature of the token 30, tiie 
coprocessor 20 stores the software decryption key 
AK In the permanent memory 25. The conditions of 
execution can be stored in ttie same file as the AK 
and can be installed at ttie same time, as AK. In ttie 
case shown in Rg. 2, the coprocessor 20 stores 
the datum which can be interpreted as a tenminal 
date and/or time. This interpretation will be per- 
formed by the protected part of the application on 



any occasion of its use. The terminal date storage 
is associated with the software decryption key AK, 
as shown In Rg. 3. More particuiariy, Rg. 3 is 
entirely identical to Rg. 2 except ttiat it shows ttie 

5 software decryption key AK. and the terminal date 
and/or time, stored in the coprocessor 20*8 perma- 
nent memory as well as indicating that the token 
30 has been depleted. Thereafter, each time ttie 
protected application is run on tiie coprocessor 20. 

10 prior to auttiorizing execution, ttie application uses 
tiie criterion stated in tiie encrypted application file 
tiiat ttie cunrent date and/or time not be later ttian 
ttie tenminal date and/or time and only auttiorizes 
execution In the event the criterion Is met The 

75 current date and/or time is supplied on demand by 
tiie coprocessor 20 to the executing application. 

Rg. 4 is similar to Rg. 3 except ttiat ttie 
conditions stated in the encrypted application key 
file gives the remaining number of authorized ex- 

20 ecutions. On installation of the right to execute, the 
software decryption key AK is associated with a 
count C; each time execution of the application is 
requested, the co n te n ts of the count C is tested 
against ttie criterion that the number 0 of au- 

25 tiiorized executions remaining is greater than zero. 
The count C is then decremented. Only so long as 
C is greater than zero will execution be auttiorized. 

It may be advisable, regardless of whettier or 
not the condition is a terminal date and or time, or 

30 a number of executions, to provide tiie coprocessor 
20 witti instructions to delete tiie associated soft- 
ware decryption key AK, once the initial conditions 
are no longer met. Thus, the software decryption 
key AK is automatically removed from the pemna- 

35 nent memory and ttius ttie right to execute is 
deleted. 

Rgs. 5-7 are useful in illustrating transfer of the 
right to execute. As shown in Rg. 5. the coproces- 
sor 20 has Installed the right to execute a particular 

40 protected application in ttie fonm of ttie software 
key AK in its permanent memory 25. The user, in 
order to effect the transfer of ttie right to execute, 
obtains a transfer set The transfer set includes a 
token 40 and an accompanying disk 46. The token 

45 40 had been loaded via a trusted source such as 
the coprocessor hardware manufacturer with token 
data T2, and the disk is written with the token data 
encrypted under the hardware vendor's key so ttie 
disk stores tfie file EcsxOa). The user also has 

60 available his original source disk 16 which includes 
the files enumerated in Rg. 5. 

Rg. 6 shows the condition of these compo- 
nents after tiie first step in ttie transfer sequence 
has been completed. More particuiariy, ttie disk 46 

55 of the transfer set is read, and its contents are 
decrypted so that tiie coprocessor 20 can store, in 
its temporary memory 26 the token data Tz. The 
software decryption key AK to be transfen^ed, is 
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moved from the permanent memory 25 to the 
temporary memory 26. 

The next step in the transfer sequence is to 
encrypt the token descriptor T2 using the key RK 
(to obtain Erk(T^) and to write a number of files 
onto the disk 46. The application file A (plain text), 
the encrypted application file EAK(appncation file 
B), the software decryption key E csk(AK) 
(prepared If need be as previously described) and 
the encrypted token data Eaic(T^. Thus at the con- 
clusion of the steps shown in Rg. 7, the disk 46 of 
the transfer set is substantially identical to the 
original disk 16 which the user had acquired. The 
differences are that the token data (which exists in 
encrypted form) is different on the disks 46 and 16 
and if the conditions of execution "(such as count) 
have changed a new encrypted application key file 
Ecsk(AK) has been used. This file Is associated 
with the new token through the synchronous 
mechanism described previously. Transfer Is thus 
made useless as a piracy method. Of course In 
installing the right to execute on the coprocessor 
20, the user had used (and hence Invalidated) his 
token containing the token data Ti, and as a result 
the file set on the original disk 16 is not usable to 
install a right to execute in another coprocessor. 
However, the disk 46 includes the encrypted token 
data corresponding to the token 40 which is now in 
the user's possession. Accordingly, the user is now 
in a position to install the right to execute the 
protected application on another coprocesson note 
at the same time that the original coprocessor 
which previously stored the software decryption 
key AK. no longer stores that key. Accondingly, the 
right to execute the protected application has been 
transferred from the coprocessor 20 to the portable 
form represented by the distribution set including 
the cartridge 40 and the disk 46. 

While the transfer set including the disk 46 and 
the cartridge 40 could be used to install the right to 
execute the protected application on a different 
coprocessor, it is also usable as a form of extemal 
storage for the right to execute, e.g. the user could 
If he wished install the right to execute back into 
the coprocessor 20 from which it was derived in 
the first place. 

The direct transfer, from coprocessor to 
coprocessor, of a right to execute Is shown in Rgs, 
20 and 21 . Rg. 20 shows that a source composite 
processor includes a host 10 and coprocessor 20, 
a sink composite processor includes a sink host 
110 and a sink coprocessor 120. As shown in Rg. 
20. the source coprocessor includes the right to 
execute (AK) which is to be transfen-ed. In general, 
both coprocessors 20 and 120 would contain the 
same collection of supervisor keys (CSIQ; for gen- 
erality purposes Rg. 20 shows that the source 
coprocessor will, in the following process, employ 



the supervisor key CSK1, whereas the sink 
coprocessor 120 will emptoy a different supervisor 
key, CSK2. Nelttier coprocessor has a priori knowl- 
edge of which supervisor key is employed by the 
5 other. The source and sink processors are inter- 
connected via a communication link 200. 

As already described, once communication is 
established, the coprocessors begin an identifier 
sequence to ensure themselves that the other is a 
10 "member of the family". In step 1 of Rg. 1 outlin- 
ing this process, each coprocessor generates a 
random number, so that the source coprocessor 
generates RN1 and the sink coprocessor generates 
RN2. In step 2 each of the random numbers are 
15 encrypted under a supervisor key independently 
chosen by the generating coprocessor and the 
encrypted information is transferred, so that in step 
3 the sink coprocessor 120 has access to Ecski- 
(RN1) and the source coprocessor has access to 
20 EcsK2(RN2). As previously explained, only 
"members of the family" are capable of decrypting 
and recognizing the random numbers transmitted 
thereto. Assuming that the source and sink 
coprocessors are "members of the family", then 
25 each can decrypt the transmitted message so that 
thereafter both coprocessors have available RN1 
and RN2. As already indicated, the session key SK 
is a composite of both the random numbers, and in 
step 4 of Rg. 21 each coprocessor Independently 
30 determines the identical session key SIC 

Thereafter, after the user has identified the 
right to execute which is to be transferred (AK), the 
source coprocessor encrypts the right to execute 
under the session key SK and transmits It to the 
35 sink coprocessor (step 5). At this point while the 
sink coprocessor 120 has access to the right to 
execute, AK, It is not yet effective. This lack of 
effectiveness is enforced by the trusted safe proce- 
dures Imposed on each of the coprocessors. Tfie 
. 40 sink coprocessor returns a message to the source 
(step 6) indicating receipt of the right to execute. 
Consequently the source coprocessor can delete 
the right to execute (step 7). Rnally, the source 
coprocessor (step 8) transmits a message to the 
45 sink coprocessor that the right to execute has been 
deleted. Only thereafter, in step 9, does the sink 
coprocessor activate the right to execute. 

Having described direct transfer of a right-to- 
execute, or a collection of rights-to-execute it Is a 
50 simple extension to describe safe procedures for a 
library type of software distribution among comput- 
ers in a networic. For the reasons already given 
protected software can only be distributed to com- 
posite computing system as heretofore descrit)8d, 
55 i.e. each consists of a host (for example a PC) and 
a coprocessor. It should be clearly understood that 
protection is preserved even if some of the partici- 
pants in the network are not composite computing 
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systems as previously described. The only con- 
sequence of the existence of such interlopers Is 
that the protected software is simply unavailable to 
them. In such a network any pair of such compos- 
ite computing systems can safely transfer right(s)- s 
to-execute by the procedures already described. 
The fact that transfers may be observed (and 
copied) is of no moment for the reasons already 
given. One observing a transfer of a right-to^x- 
ecute would merely observe encrypted messages . lo 
pasdng back and forth: without access to the su- 
pervisor or session keys protection is preserved by 
the inability to decrypt or read any of the mes- 
sages. In Quch a network there may exist one or 
more software sources in the sense that a source is 
has available many right(sHo-execute. including, 
typically, multiple rights for a single protected ap- 
plication. Cleariy such a source may transfer a 
right-to-execute (assuming that the software flag 
allows transfer) to many other, composite comput- 20 
ing systems. Each time a right-to-execute is trans- 
fen'ed the source's collection of rights is reduced 
by the transfen-ed right, and each time a right is 
returned the source's collection of rights is aug- 
mented by that return. The permanent memory of 25 
any source always retains a count of available 
rights and at any time transfer of ^e or all of the 
available rights can be effected. Mt should also be 
apparent that a source may condition a transferred 
right, such as for example requiring the transferee so 
user have an account which is. charged for the 
transfer. The transferred right could also be con- 
ditioned in terms of time or number of uses. etc. In 
some cases, for example if a transferred right is 
conditioned to expire on a date in the future then 35 
the source may be arranged to increment its col- 
lection of rights-to-execute on passing of the date 
in an implied transfer transaction. In other words 
since the transferred right was conditioned to ex- 
pire on the spedfted date it is quite appropriate for 40 
the source to ^'reacquire" the previously transferred 
right after the specified date even though no actual 
transfer took place. A source may also retain a 
count of available rights measured by the number 
of executions, and of course such a source could 45 
transfer all or a part of such collection in one or 
many transactions. Some of those rights could also 
be retumed to augment the source's collection. 

In any transfer transaction the only necessary 
data actually transferred from coprocessor to so 
coprocessor is the encrypted key (and assodated 
flags and conditions); the protected software itself, 
both encrypted and plain text portions, can be 
transfen-ed by any corwentional means. If efficient, 
all composite computing systems could have pre- 55 
existing access to all (or less than all) of the 
protected software (in encrypted form) so only the 
key need be transferred. Software which must be 



transferred could be transferred through the same 
network by which the keys are transferred or the 
software could be transfenred through another net- 
work such as the postal service. 



Backup the Right to Execute 

In the foltowing description, reference Is repeat- 
edly nrtade to "reading" a token; the structure of 
the hardware cartridge storing the token, and the 
manner in which it is read is described tnorB fully 
in [YO985-091]. [YO986-010L the disclosure of 
which is incorporated by this reference. 

Because- the entire backup sequence refers to 
a failed coprocessor and installs the right to ex- 
ecute on a different coprocessor, we will refer to 
the failed coprocessor as the source coprocessor 
and the different coprocessor as the sink coproces- 
sor. 

tt should already be dear that the right to 
execute, In the fonrn of a software decryption key 
AK is stored in the (source) coprocessor 20. 

While the coprocessor 20 has features which 
make it unique, it is similar in at least one respect 
to any other processor. i.e. it is capable of a failure. 
With current software distribution techniques, when 
a user has a processor failure, that failure interrupts 
his ability to execute software, but that ability can 
be reacquired by repairing or repladng the failed 
processor. In the case of the coprocessor 20. how- 
ever, failure of the device may well permanently 
Impair the right to execute which had been stored 
therein. Accordingly, software vendors may desire 
to provide their customers with a "hardware" bac- 
kup of their righits-to-execute. The "hardware" bac- 
kup which will be described herein is arranged to 
minimally impact the security of the right-to-ex- 
ecutB, e.g., limit the number and duration of any 
spurious or duplicate rights to execute. The 
"hardware" backup to be described can t>e con- 
ceptualized as a pending or inchoate transfer of 
rights. Because the necessity for the backup de- 
pends on a future and uncertain event e.g. failure 
of the coprocessor 20, It must be arranged so that 
the inchoate right to execute can be converted to 
an actual and usable right to execute entirely in- 
dependent of the processor 20. For this reason, it 
does have the feature of generating a duplk^te 
right to execute which could be used by the un- 
scrupulous to thwart the protection sought by the 
software vendor. However, as will be described, tiie 
installation of a backup can only be perfonmed 
once for any (source) processor and produces a 
conditioned right to execute, conditioned on a 
grace period (typically measured from the time of 
the backup installation). At the conclusion of the 
grace period, in the absence of further action, the 
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rights to execute derived from the t>ackup rights 
are no longer effective. The cost of this severely 
limited piracy to the unscrupulous is the sacrifice of 
the possibility of reclaiming that collection of rights 
to execute in the event of a real coprocessor fail* 
ure. In the case of a scrupulous user, in the interim, • 
the user is obligated to "prove" to a trusted ob- 
server, such as the hardware vendor, that his 
coprocessor indeed has failed. Typically, this 
"proof" is effected by physically transmitting the 
failed coprocessor to the hardware vendor. On re- 
view of the failed coprocessor, the hardware vendor 
will provide to the user a verification disk. The 
verification disk can be used by the user to provide 
validated authorization to the (sink) coprocessor to 
eliminate the condition on the backup rights to 
execute and convert them Into rights to execute 
conditioned only by . the condition set at the time of 
their acquisition. To ensure that the verification disk 
rs prepared based on evidence of the failure of a 
coprocessor which is identical to the coprocessor 
which originally stored the right to execute being 
replaced, the verification disk canies. in encrypted 
form, a unique identifier of the ^led coprocessor. 
This unique identifier is necessary to allow the 
removal of the condition. It is also to be desired 
that the sink processor be able to recognize that 
the message to remove the condition from the 
installed set of rights to execute is Intended to be 
received by it This is accomplished by including in 
the message a copy of the (sink) coprocessor's 
unique key to serve as validation of the message 
or by encrypting the message with the sink 
coprocessors unique key. Both the source and sink 
processor identifiers are made available to the 
hardware vendor in an encrypted (under CSK) 
message prepared by the sink processor to be 
returned with the failed source processor. 

The procedure as just outlined is graphically 
illustrated, as a function of time which proceeds left 
to right, in Rg. 17. Initially, coprocessor 20 includes 
a set of rights to execute. A CBS procedure (create 
backup set) is initiated; this creates a backup set 
incajding a cartridge and a disk. Although this 
backup set bears some similarity to the transfer 
set. as will be described below, the CBS procedure 
is preferably carried out each time the user ac- 
quires a new right to execute, so tfiat the single 
backup set provides a backup for every right to 
execute within the repertoire of the coprocessor or 
at least a backup right for each application for 
which backup is authorized by tiie software vendor. 
Fig. 17 also shows tiiat subsequent to execution of 
the CBS procedure, the coprocessor 20 fails. 
Thereafter, tiie user effects an install backup set 
(IBS) procedure at a time T g- Accordingly, subse- 
quent to time Ts tiie user can employ his rights to 
execute on the coprocessor 120 in lieu of the failed 



coprocessor 20. During that time the user can 
transmit the failed coprocessor 20 to the vendor 
who creates a verification disk as a message to the 
sink coprocessor 120. So long as the user receives 

5 the verification disk prior to the expiration of tiie 
grace period, he completes the install backup set 
procedure using the verification disk so as to re- 
move the conditional nature of the rights to execute 
in tiie coprocessor 120 (at time T e). 
. 10 Refening now to Rg. 8, tiie coprocessor 20 
has a collection of rights to execute represented by 
tiie software decryption keys AKi and AK2. It Is 
these rights which need to be backed up. The first 
step (Rg. 9) In the backup procedure is for the 

75 user to acquire an unused backup set consisting of 
token 50 and tiie disk 56. The token includes token 
data Tb which, for illustration purposes, is shown to 
consist of a number of portions. TBI. TB2, and so 
on through TBn. The disk 56 Includes tiie token 

20 data encrypted under the key CSK. The user ef- 
fects a reading of the disk and by the appropriate 
utility procedure on the host 10 the coprocessor 20 
decrypts tiie encrypted file read from tiie disk 56 
so tiiat It can store Tb in its temporary memory. At 

25 this time. (Rg. 10) the user couples the token 50 to 
the host 10 via the cartridge connector 18. The 
coprocessor 20 selects the amount of the token 
data for use; for this description we assume that 
the portion TBI is selected for use. The coproces- 

30 sor 20 generates a random number RN and com- 
putes a function of TBI and RN. denominated CR. 
the computed response of the token. The 
coprocessor 20 causes the random number RN to 
be applied to the token 50 to "read" destructively 

35 the first portion TBI. Reading this portion of the 
token 50 destroys the portion TBI and returns to 
the coprocessor 20 the actual response AR. 

Rg. 11 shows the apparatus In the configura- 
tion. e.g. the token 50 no longer stores TBI and 

40 the temporary memory Includes the actual re- 
sponse AR. 

At this point tiie coprocessor 20 compares AR 
and CR. If they do not correspond, an emsr con- 
dition has been detected, the token 50 is consid- 

45 ered unauthentic and the backup procedure termi- 
nates. On the other hand, assuming that AR and 
CR conrespond, tiien the coprocessor 20 accepts 
the token 50 as autiientic and is allowed to proceed 
furtiier In the backup sequence. Rg. 12 shows tiiat 

50 the host 10, via prompting from the coprocessor 20 
has generated a new random number for use as a 
key (RK) and has written the disk 56 to include a 
number of files. The first mentioned file is merely 
the encrypted (under RK) version of the token data 

55 as modified by tiie reading operation required to 
verify tiie authenticity of the token 15. e.g. tiie 
token data T b has been modified by deleting the 
portion TBI prior to encryption. The second file 
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created on the disk 56 by the coprocessor 20 is 
the encrypted version of the random key used to 
encrypt the token data. The third file is a copy of 
the AKs and their individual assodated flags and 
conditions encrypted under the key provided in 
encrypted form in the second file. This fiie also 
contains a copy of the unique supervisor key (USK 
source) which identifies the source processor. At a 
later time, as will be descni^ed below, in the ver- 
ification process, the verification disk will Identify 
the coprocessor whose failure has been evidenced 
to the vendor. The vertficatiQn process will proceed 
to remove the expiration condition on the set of 
rights to execute which have been installed if and 
only if the verification has correctly identified both 
the source and sink processors, the resemblance 
in structure and function of this set of files and 
hardware to those in the acquire right to execute or 
transfer transactions should be obvious. At this 
point, it sufflces to note that the user has a backup 
set token 50 and disk 56 in which the clear text 
token data in the token corresponds to the encryp- 
ted token data In the disk 56. These devices are 
sufficient to allow a user to install the rights to 
execute AKi and AK2 on any coprocessor; because 
the procedure used to install these rights is an IBS. 
the set of rights to execute when installed will be 
conditioned by the grace period. 

If. subsequent to creating the backup set 
shown in Rg. 12, the user obtains a right to ex- 
ecute another application, application 3. and installs 
that right to execute AK3 in the coprocessor 20, he 
can employ the backup set to create a backup set 
encompassing not only AKi and AK2, but also AK3. 
In that event the user presents the disk 56 to the 
composite computing system wherein the encryp- 
ted token data is read. The user then performs the 
steps already described with relation to Figs. 9-12. 
in the course of this process, the token portion TB2 
will be destroyed in verifying the token; thereafter 
the resulting token data will consist of TB3 . . . 
TBn, the encrypted token descriptor file on the disk 
56 will con-espond and the disk 56 will Include the 
encrypted version of AK3. If tiie user had made 
copies of disk 56 prior to this point, these disks 
would now be useless for either CBS or IBS trans- 
actions as the encrypted token descriptor and RK 
on these disks would not correctly validate the 
backup token. 

Of course, the user can continue using the 
backup set consisting of the token 50 and the disk 
56 until there is only a single token descriptor 
portion left in the token 50. At this point, a new 
backup is required if another CBS is to be per- 
fomied. The last portion of tiie backup token may 
be read by the coprocessor to invalidate tiie old 
backup, and a new backup set may be started. 

In the event the coprocessor 20 falls, the user 



can employ tiie backup set consisting of the token 
50 and the disk 56 in an Install Backup Set (IBS) 
procedure which is described betow. beginning 
with reference to Fig. 13. 

5 As shown in Rg. 13, tiie user has presented 
the backup set to a different composite computing 
system consisting of a host 110 and a coprocessor 
120; it is not at all essential that the host 110 be 
different from ttie host 10 in the original composite 

TO computing system, It is only necessary that the 
coprocessor 120 be different from the failed 
coprocessor 20. As shown in Rg. 13, tiie coproces- 
sor 120 does not contain any rights to execute in 
its permanent memory. When tiie user presents 

75 the disk 56, the encrypted random key Ecsk (^K) Is 
read and decrypted so ttiat the encrypted token 
data Erk(TB2 TB3 . . . TBn) can be read from 
the disk and decrypted as shown in Rg. 14. The 
temporary memory now includes tiiat token de- 

20 scriptor in plain text fomi. The coprocessor 120 
then generates anotiier random number, SRN, and 
computes a function of a selection portion (TB2) of 
the clear text token data and the random number 
SRN; denominated as CR. The coprocessor 120 

25 then interrogates tiie token and In doing so de- 
stroys tiie next portion TB2 and generates an ac- 
tual response AR. Rg. 14 Is a snapshot of tiie 
apparatus at this point. The coprocessor 120 tiien 
detemnlnes if AR and CR correspond. If they do 

30 not, then the token 50 Is not considered authentic, 
an en'or condition Is entered and ttie Install Backup 
Set procedure is terminated. On ttie ottier hand, if 
AR and CR do connespond, then tiie Install Backup 
procedure continues. 

35 In ttie next step (which is not spedfically Illus- 
trated), the encrypted file containing AKi, AK2 and 
USK (source) are read from ttie disk 56, decrypted 
and stored in the permanent memory along with 
ttieir Individual conditions and an indication that 

40 tiiey are all conditioned by the grace period. 

The sink coprocessor now prepares a message 
to tiie hardware vendor which Is encrypted under a 
supervisor key CSK .and is stored on disk by ttie 
host. The message contains a copy of the unique 

46 supervisor key (USKs) of both the source and sink 
processors encrypted under a common supervisor 
key EcsK(USKsource and USKsink). This informa- 
tion is used to verify ttiat the failed processor 
presented to the hardware vendor is the source 

60 processor and to prepare a verification message 
which will only allow that sink processor to relieve 
the expiration date condition from that source pro- 
cessor's set of rights. 

With coprocessor 120 in this condition, the 

55 user can execute protected application enabled by 
AKI and AK2 during ttie duration of ttie grace 
period. The grace period is measured beginning at 
the perfomnance of ttie IBS. In ttie absence of 
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completing the IBS during the grace period, the 
rights to execute are suspended but may be re- 
instated by completing the IBS. 

Assuming, however, that the user obtains the 
appropriate verification disk from the vendor, then 
the IBS procedure can be completed as shown In 
Fig. 15. As shown In Rg. 15, the user has pre- 
sented to the composite computing system the 
verification disk 66. The verification disk 66 in- 
cludes a single file encrypted under the unique key 
of the sink processor which carries within It a copy 
of the unique supervisor key identifying the source 
coprocessor (EusKsfnk(USKsource)). whose failure 
has been proved to the vendor. The coprocessor 
120 reads the verified disk 66 and decrypts the file. 
The coprocessor 120 can then compare the con- 
tents of the verify file with the copy of the source 
USK it has stored. If they do not con-espond. an 
error condition is detected, and the conditional 
rights to execute remain conditioned; they will be 
suspended with the expiration of the grace period. 
Oct the other hand, assuming the^verify file does 
correspond in all respects, then the coprocessor 
120 Is authorized to take the final IBS steps; these 
delete the conditional nature of the set of rights to 
execute AKi and AK2. At the completion of the IBS 
procedure (Fig. I6)t the coprocessor 120 includes 
rights to execute AKi and AKa (conditioned only by 
their conditions at time of source processor bac- 
kup) in its permanent memory. In this condition it is 
in an identical condition* as the coprocessor 20 just 
prior to the time it failed (Rg. 8). Thus the fore- 
going steps provide for a "hardware" backup for 
the coprocessor 20 with minimal impact on the 
security of the software vendor's rights, e.g. un- 
authorized duplication of the right to execute. 

The backup procedures employing a token use 
the token and the procedures associated with it to 
validate to any coprocessor to which the set is 
presented, that it can accept the rights ta execute 
which are represented by the set When an 
'Intermediate" coprocessor is employed for bac- 
kup purposes, the token is unnecessary; it is the 
procedures which govern the coprocessors (and 
which are beyond the reach of the user) which 
provide the safety. Thus, in the case of using an 
"Intermediate" coprocessor for backup purposes, 
the disk 46 is prepared essentially similar to the 
manner in which It is prepared when a token/disk 
pair are used except of course that the disk file 
representing the token data is completely unnec- 
essary. Perhaps the only other difference is that 
when the backup set was employed, the decryption 
key is encrypted under a supervisor key; such an 
anrangement If used without the cautions might 
allow any coprocessor to whom such a disk was 
presented to accept the backup. To prevent this, 
the key under which the decryption key is encryp- 



ted is a Session Key. which is generated between 
the source coprocessor and the "intermediate" 
coprocessor. The generation of such a Session 
Key has already been described; the only informa- 

5 lion stored by the "intermediate coprocessor" is 
the Session Key. along with an indication that it is 
associated with a backup. Because the transfer 
procedures require invalidation of any existing bac- 
kup, the "intermediate" coprocessor can be as- 

70 sured that if it has the Session Key available, any 
Install Backup Set procedure is valid. And. as has 
already been descrilsed, the backup set can be 
installed on a "sink" coprocessor so long as the 
"intermediate" coprocessor transfers the Session 

75 Key to the sink coprocessor. 



Encrypt Vendor Key (EVK) 

20 As described herein, the majority of coproces- 
sors will be employed in a user's composite com- 
puting system (including, in addition to the 
coprocessor, the host) for the execution of pro- 
tected application software. In this setting the 

25 coprocessor has the function of storing in a pro- 
tected fashion rights to execute one or more pieces 
of software as well as the function of manipulating 
such right or rights as ^described above. As is 
already described, however, that is not the only 

30 function of the coprocessor; coprocessors are also 
required by the software vendor in preparation of 
the distributable package. While the software ven* 
dor could employ any computing system to pro- 
vide for the encryption of token data and software 

35 under his own secret key (AK) in accordance with 
the software protection mechanism described in 
copending application [YO985-091], another com- 
ponent of the distributable set Is the software de- 
cryption key, encrypted under the hardware ven- 

40 dor's key, e.g.. Ecsk(AK). In order to secure the 
hardware vendor's key CSK from knowledge by the 
software vendor, the software vendor can use a 
coprocessor (which is equipped with the key CSK 
in secure storage) for this function. It is already 

45 described that this service can be used to facilitate 
a plain text attack on the key CSK. 

White we have postulated the use of DES. 
which is particulariy resistant to the plain text at- 
tack, by using the procedures described below that 

50 resistance can be enhanced. The plain text attack 
requires the attacker to have access to plain text 
and cipher text encrypted under the key under 
attack. By use of the procedures to be described, 
we deny the attacker access to such information. 

65 Rg. 18 shows a typical coprocessor 220 used 
In the mode required by the software vendor 
wherein input is one or more software decryption 
keys AKi, AKs, etc.. and output is the keys encryp- 
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ted under the key CSK. Using the convention al- 
ready established, the coprocessor 220 is phys- 
ically and logically secure; that security is indicated 
by the dashed inner boundary. If the coprocessor 
220 merely outputs Ecsk(AK) for each software 
decryption key input, it woukj readily provide an 
attacker with the data necessary for a chosen plain 
text attack. 

In accordance with this aspect of the invention, 
however, the coprocessor 20 modifies the decryp- 
tion key prior to encryption; the modification, how- 
ever, fs one of which all coprocessors are aware, 
so that all other coprocessors can perform the 
Inverse modification. In general, each software de- 
cryption key AKi is modified by padding it, front 
and rear. More particulariy, as shown in Rg. 18, a 
suffix recognition flag (RF) typically in the form of a 
message authentication code (MAC) of known bit 
length Is used along with a prefix random number 
(RN). Thus, in response to presentation of AKi. the 
coprocessor 220 generates RNi^Kt.RF (where . 
indicates concatenation). The coprocessor there- 
after encrypts the resulting concatenation of data 
blocks under some key CSK among the set of 
CSKs to produce Ecski(RNi.AKi.RF), It is self-evi- 
dent from an understanding of the DES that arh 
other coprocessor with access to CSKi can decrypt 
the result to produce the string RNiAKtRF. Be- 
cause the decrypting coprocessor has a priori 
knowledge of the content and bit length of RF as 
welt as the bit length of a spftware decryption key 
such as AKi. it readily follows that the coprocessor 
can decrypt the message Ecsw (RNi.AKi.RF) with 
each of the set of CSKs until the RF decrypts 
conrectly. Once the Coprocessor has found the 
correct CSK and has decrypted the encrypted in- 
formation it can also segregate and specifically 
identify AKi; the prefix RNi is merely discarded 
(unless as stated earlier it is needed to perform 
some other verification task). 

An understarKling of DES should also make it 
apparent that whereas a plain text attack requires 
knowledge of sets of plain text and encrypted in- 
formation such as AKi. E(AKi); AK2. E(AK2); AKj. E- 
(AKs); and so on. someone with access to the 
coprocessor 220 may readily be able to identify the 
following sets: AKi. Ecski(RNiAKiRF); AK2. Ecsiq - 
(RN2.AK2.RF); AK3. EESKk(RN3^K3.RF); and so on. 
This set or sets of plain text and encrypted data is 
of substantially less assistance to the attacker In 
attempting to identify the key under which these 
various strings are encrypted, even with knowledge 
of the plain text AKi. AKa. AK3, and so on. 

Accordingly, the coprocessor 220, representing 
all coprocessors employed by software vendors for 
encrypting their software decryption keys, performs 
the following Encrypt Vendor Key (EVK) procedure. 
A utility program signals ttie coprocessor 220 tiiat 



a EVK sequence is about to begirt The coproces- 
sor 220 requests and is given the vendor key AK to 
be encrypted. The coprocessor 220 generates tiie 
random number (RN) and uses It as a prefix to pad 

5 tiie front end of tiie key AK. The coprocessor 220 
also pads the back end. using the recognition flag 
(RF) as a suffix. The resulting block or string is 
encrypted under the supervisor key CSK and tiie 
result is passed to the host 

10 This EVK procedure has tiie property tiiat by 
property selecting the recognition flag, a data block 
can be encrypted, under a selected supervisor key. 
selected by one coprocessor, and the encrypted 
block can be decrypted by another coprocessor 

76 even though tiie decrypting coprocessor does not ' 
have a priori knowledge of which of the supervisor 
keys has been selected for the encryption, so long 
as the decrypting coprocessor has access to a set 
of supervisor keys which Includes all possible su- 

20 pervisor keys. This can be accomplished by a 
number of means including a priori knowledge in 
t)oth processor, message authentication codes and 
by selecting, as the recognition flag (RF) the en- 
crypting supervisor key. For example assume that 

25 tiie encrypting coprocessor selects CSK3 for tiie 
purpose of encrypting AKn. By tiie foregoing proce- 
dure, the encrypting coprocessor produces Ecskt 
(RN.AKn.RF). We assume for this purpose ttiat tiie 
decrypting coprocessor has access to all CSKs, 

30 although it is not aware of which CSK has been 
selected for tiie encryption. The decrypting 
coprocessor begins witii CSKI, and decrypts tiie 
encrypted block, with each decryption key in tum. 
Each time tiie block Is decrypted, the suffix is 

35 compared to tiie decryption key. When tiie suffix 
and the decryption key match, the decrypting 
coprocessor has identified the encryption key and 
at the same time has access to AKn since tiie block 
has already been decrypted using the correct de- 

40 cryption key. Similarly, if a priori knowledge is 
used the expected string must be found In the RF 
position or if a MAC Is used then the MAC must be 
valid for tiie AK„ or for RN.AK„. 

Throughout tiie previous description reference 

45 has been made to the software decryption key AK. 
For reasons which are described below, tiie bUxk 
referred to as AK may include not only the software 
decryption key. but several flags, the conditions of 
which are selected by the software vendor so as to 

50 allow or not to allow certain procedures to be 
performed. For example, al-bltflagcanbesetto 
either allow or not a}k)w "hardware" backup proce- 
dures to be employed. In tiie event tiie "hardware" 
backup flag is set to disallow the backup proce- 
ss dure, tiien any coprocessor storing tiiat decryption 
key would limit the backup procedures to exclude 
tiiat key (and any otiiers so marked). The software 
vendor may wish to prevent transfer of a software 
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decryption key once Installed. For this purpose, a 
1-bit transfer flag may be provided which will either 
allow or disallow the transfer operation. If a host 
requests a transfer procedure, that procedure is 
allowed only if the transfer flag, is set to allow the 
transfer operation. Each of these limitations are to 
be understood as data provided to the functions 
provided In each coprocessor. AKs may also con* 
tain the aforementioned conditions of execution 
which are tested by the individual applications. 

Rg. 19 is an example of the appearance of a 
portion of tiie permanent memory 25 of a typical 
coprocessor which has been in use for some time 
and stores a collection of rights to execute. As 
shown in Rg. 19, the permanent memory 25 in- 
cludes a record (or entry) for each of a plurality of 
different keys, CSKI through CSKn, AK1 tiirough 
AKn and:riAAK1 and MAK2 are illustrated in Rg. 19. 
Eachrrecord includes a number of fields, one of the 
fietcte-: Is the key itself. Associated witii each key 
ace?a number of binary flags, a bit for each of the 
fallowing: Meta. Condition. Erase, Transfer and 
Backup. It should be understood tiiat this list is a 
useful subset of such flags and that the set would 
almost certainly be extended by one skilled in tiie 
art The binary flag identifies, for example under 
the first column, whether or not the key is a Meta 
key and as shown In Rg. 19 only tiie last two 
records indicate storage of Meta keys. In the next 
column (headed "Condition"), a binary 1 indicates 
that the key Is conditioned and as shown in Rg. 19, 
keys Al^ and AKn are conditioned. The third col- 
umn (headed "Erase") indicates, by tiie binary 0, 
ttiat a erasure of the key is not permitted; tills 
condition appliey to each of the supen^isor keys as 
well as to a particular application key AK2. The 
fourth column, headed "Transfer" Indicates, by tiie 
binary 1, that all keys except AK1 are auttiorized 
for transfer (except for tiie supervisor keys, the 
transfer of tiiese keys is not at all necessary nor 
desirable). The last column under tiie binary flag 
poretion of Rg. 19 is headed "Backup", and the 
binary 1 indicates that the associated key is au- 
thorized for backup. As shown in Rg. 19, keys AK3 
and AKn are not authorized for backup. 

The memory depicted in Rg. 19 includes a 
number of multibyte entries for each of tiie keys. 
One of the multibyte entries Is headed "Condition" 
and this field includes the data associated witii a 
conditioned key. and tiius keys AK3 and AKn in- 
clude data In tiiat field which can be tested by 
criteria stored in the application they decrypt to 
determine if execution is authorized. The last col- 
umn In the multibyte entry portion of Rg. 19 pro- 
vides location and verification information which aid 
searches for an applications key and verification of 
tiie key as tiie one sought. 



Software Return 

From the foregoing description it should be 
apparent that the procedures described for man- 

5 tpulating rights to execute allow tiie software ven- 
dor to institute a software return policy which is fair 
to his customers as well as to himself. For eco- 
nomic reasons, some vendors may desire to limit 
the retum of software to some fixed period (akin to 

70 a wanranty) although tiiat has no bearing on the 
present invention. A software vendor may for ex- 
ample allow tiie retum of software (for full or partial 
credit at the vendor's selection), by requiring tiie 
user to provide the vendor with a transfer set 

75 including the right to execute the particular soft- 
ware application package. The manner in which the 
user can create such a transfer set has already 
been described. If tiie user presents to the software 
vendor a valid transfer set including the particular 

20 application package for which retum is sought, the 
software vendor is assured (by the operation of the 
software copy protection mechanism) that the user 
himself no longer retains the right to execute tiiat 
software. As is described above, creation of a 

25 transfer set requires deletion of the decryption key 
from tiie coprocessor. 

it should be apparent from the foregoing tiiat 
the invention provides wide flexibility for manipulat- 
ing rights to execute in the software protection 

30 mechanism described In copending application 
[YO985-091]. The present application describes 
several of these procedures by describing the logi- 
cal operations and their interrelation. To generate 
from the description provided herein, software to 

35 execute those logical op)erations will be apparent to 
thosa. skilled in the art and hence a specific de- 
scription of software to implement the procedures 
which have been described Is deemed unneces- 
sary. 

40 The techniques taught herein for tiie manipula- 
tion of rights to execute can be used for more 
general operations as well: examples are described 
briefly in the following: 

A) A method of identifying companion pro- 

45 cessors to each other which companion processors 
are characterized by storing a set of keys, which 
set includes a number of keys greater than one, 
comprising the steps of: 

a) generating a random number at one 

50 processor, concatenating said random number with 
a message authentication code, to produce a con- 
catenated result and encrypting said concatenated 
result under one key of said set of keys to produce 
a first identifier. 

55 b) generating a random number at said 

other processor, concatenating sakl random num- 
ber, with a message authentication code, to pro- 
duce a concatenated result and encrypting said 



20 



39 



0 268 139 ' 



40 



concatenated result under another key, said ar>- 
other key selected by said other processor from 
said set of keys, to produce another identifier, 

c) transmitting said one and another iden- 
tifiers to said other and one processors, respec- 
tively. 

d) verifying, at said processors that said 
Identifiers were generated by companion proces- 
sors by: 

1) decrypting said identifiers with keys selected 
from said set of keys until a decrypted result 
ihlcudes a valid message authentication code as a 
portion, or 

e) not verifying said processors are com- 
panion processors if all keys in said set are em- 
ployed without any decrypted result including a 
valid message authentication code. 

B) A method of Inter-processor communica- 
tion which restricts exchange of key Information to 
within a class of companion processors which are 
characterized by storage of a set of keys greater in 
number tiran one, said method comprising the 
steps: 

i) using tiie above-described mettiod of 
identification, 

' ii) combining said one and anotiier Identifi- 
ers at botii said processors to produce a session 
key, and 

iii) exchanging key information by first en- 
crypting said key information under said session 
key and transmitting said encrypted key Informa- 
tion from one to said other or from said other to 
said one processor. 

C) A method of safely increasing storage 
capacity for software keys normally stored within a 
logically and physically secure finite store acces- 
sible to a logically secure coprocessor element of a 
composite computing system without comprising 
security of said software keys comprising the steps 
of: 

a) selecting one more software keys for 
storage external to said logically and physically 
secure storage to form a key block, 

b) generating a random number, 

c) encrypting said key block under said 
random number to produce an encrypted key 
block, 

d) storing said random numt)er internally 
to said physically and logically secure coprocessor, 

e) storing said encrypted key block exter- 
nal to said physically and logically secure 
coprocessor in otiierwise unsecured storage, and 

f) erasing said software keys from storage 
intemal to said togically and physically secure 
coprocessor. 

D) A method of storing and retrieving a set 
of software keys stored extennal to a physically and 
logically secure coprocessor element of a compos- 



ite computing system without comprising security 
of any of said set of software keys, wherein said 
coprocessor has access to a set of supervisor 
keys, said metiiod comprising tiie steps of: 
5 I) storing said software keys as recited in claim 18. 
il) retrieving said encrypted key block and said 
encrypted key from said external storage, 
Iii) decrypting said encrypted key with a selected 
one of said supervisor key and verifying tiie pres- 
. 10 ence of a valid message autiientication code, 

iv) repeating step iii) with each different supervisor 
key until one such step results in a valid message 
authentication code, 

v) decrypting said enaypted key block with that 
75 unselected protion of the result of step iv), 

whereby a result of said step v) is the original key 
block including each of said selected software 
keys. 

20 

Ciaims 

1. A metiiod of manipulating a right to execute 
In a logically secure coprocessor (20) associated 

25 with a host processor (10), where said coprocessor 
stores at least a first key (CSK) and a second 
software key (AK) representing said right to ex- 
ecute a particular application, said host processor 
having access to said particular application encryp- 

30 ted under said second software key, said metiiod 
comprising the steps of: 

a) providing to tiie coprocessor a transfer set 
including at least a writable medium (46) and a 
physically and logically secure medium (40), said 

35 physically and logically secure medium storing 
clear text token data (T2). 

b) providing to said coprocessor a data block 
(EcsK {T2)) comprising said clear text token data 
encrypted under said first key, 

40 c) decrypting said data block, In said 

coprocessor to produce said clear text token data. 

2. The method of claim 1 including furttier 
steps to safely extract the right to execute: 

d) encrypting said clear text token data in said 
45 coprocessor under said second software key (AK) 

to produce a corresponding data bk)ck, 

e) encrypting said software key under said frist key 
to produce an encrypted software key, and 

f) writing said corresponding data block, said en- 
50 crypted application file and said encrypted software 

key to said transfer set and deleting said software 
key from said coporcessor. 
whereby said software key is removed from said 
coprocessor and written to said transfer set 
55 3. The method of cl^m 2 Including furtiier 
steps to transfer a right to execute to a different 
host processor ^ associated with a different 
coprocessor 
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•providing said transfer set to said different 
coprocessor storing said first key but not said 
software key. and 

1) extracting and decrypting said software key, 

2) extracting said cooesponding data block and 
decrypting said corresponding data block to pro- 
duce corresponding dear text data, 

3) reading said physically and logically secure me- 
dium to determine whether said clear text token 
data does or does not con^spond to said cor- 
responding clear text data, said reading step nec- 
essarily altering said clear text token data is stored 
in said physically and logically secure medium. 

4) if said data do not con^spond, 

a) rejecting said transfer. If said data do corre- 
spond, 

b) storing said decrypted software key, whereby 
said: reading step (3) destroys said clear text token 
data: sa that no further transfers may be authorized 
by said physically and logically secure medium. 

4. The method of claim 1 including further 
steps to provide backup for a right to execute: 

d) challenging said phy^cally and logically 
secure medium (40) to verify that the decrypted 
token data corresponds to the token data stored by 
said physically and logically secure nnedium, 

ei) in the event there is no con^spondence. 
rejecting said backup set and terminating ssud 
steps, 

eii) in the event there is conrespondence, 

then 

f) modifying and then encrypting said de- 
crypted token data under said software key. 

g) encrypting said software key under said 
first key. and 

h) writing results from said steps f) and g) to 
said backup set and writing said protected applica- 
tion to said backup set. 

5. A method as claimed in claim 4 which 
includes the further steps of: 

gl) requiring presentation to said coproces- 
sor of any previously written backup set, 
g2) invalidating said backup set, and 
gS) only after executing said step gl) and 
step g2), if there was any previously written backup 
set, proceeding to execute said step h). 

6. The method as claimed in claims 4 or 5 in 
which said step d) includes: 

modifying said token data stored in said physically 
and logically secure medium so that thereafter said 
physically and logically secure medium stores 
modified token data 

7. The metiiod of any claims 4-6, Including 
further steps to install the backup set on a different 
coprocessor: 

k) presenting said backup set to said dif- 
ferent coprocessor. 



1) passing said encrypted modified token 
data to said coprocessor and decrypting said token 
data so tiiat said coprocessor has access to de- 
crypted modified token data, 
5 m) challenging said physically and logically 

secure medium to verify that ttie decrypted modi- 
fied token data con^sponds to the modified token 
data stored by said physically and logically secure 
medium, 

70 ni) in tiie event tiiere is no correspondence^ 

rejecting said backup set and terminating said 
steps, 

nil) in the event there is correspondence. 

then 

75 o) accessing, decrypting and storing in per- 

manent memory of said different coprocessor said 
software key representing a right to execute said 
protected application by a user of said different 
coprocessor, and 

20 p) conditioning said right to execute for use 

only witfiin a grace period. 

8. The method as claimed in any of the claims 
4 - 7 in which said challenging step comprises: 
generating and storing a random number in said 

25 different coprocessor, 

generating a computed response as a function of 
both said random number and said decrypted 
modified token data, 

transmitting said random number to said physically 
30 and logically secure medium, 

generating in said physically and logically secure 
medium an actual response by reading said modi- 
fied token data as selected by said random num- 
ber, 

35 transmitting said actual response to said different 
coprocessor, and 

comparing said actual response and said computer 
response. 

9. The method of claim 1 including further 
40 steps to safely dlstiibute demonstration software: 

distributing said demonstiration software on tiie 
transfer set in a form in which at least a portion 
thereof is encrypted under a software key. and 
along with said demonstration software said soft- 

45 ware key encrypted under a further key and a null 
token data file, encrypted under said software key, 
said software key including at least a condition of 
use flag Inhibiting any coprocessor from erasing 
said software key, once installed, 

50 searching said permanent memory to determine if 
said demonstration software key had previousely 
been installed, 

writing said software key to a permanent memory 
of said coprocessor only if said searching step 
55 indicates that said demonstration key had never 
been previously installed, whereafter said demon- 
stration software can be executed on said compos- 
ite computing system by decrypting encrypted por- 
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tions by said coprocessor, or 
omitting said writing step in the event said dem- 
onstratlon software key liad been previously in- 
stalled wherefore said demonstration software can- 
not be executed on said composite computing sys- 
torn, 

whereby a user may install said demonstration 
software into a composite computing system only 
on a single occasion thereby protecting software 
vendors from users repeatedly installing demon- 
stration software. 

10. A method of manipulating a right to ex- 
ecute a particular protected application on a com- 
posite computing system including a host proces- 
sor (10) and a physically and logically secure 
coprocessor (20), wherein said protected applica- 
tion includes at least a portion encrypted under a 
software key and said right to execute is repre- 
sented by said software key sorted in a permanent 
memory of said coprocessor which coprocessor 
also stores a first key (CSK) in said pemianent 
memory, said method comprising the steps of: 

a) coupling said first coprocessor (20) to a 
second coprocessor (120) for bidirectional commu- 
nication, 

b) challenging said second coprocessor to 
determine if it is a trusted' recipient and simulta- 
neously transferring antecedent Information to said 
second coprocessor to allow access to an encryp- 
ted entity, 

c) if said second coprocessor is considered 
a trusted recipient, encrypting said software key 
under a specific key, derivable by a trusted recipi- 
ent from said antecedent information, to produce 
an encrypted software key and transmitting said 
encrypted entity to said second coprocessor, 

d) if said second coprocessor is not consid- 
ered a trusted recipient then retuming an en^or 
condition and terminating step c. 

11. A method as recited in claim 10 in which 
said second coprocessor is considered a trusted 
recipient only if It stores a set of cryptographic 
keys (CSK1, CSK2..) in common with a set of 
cryptographic keys stored in said first coprocessor, 
wherein said step b) comprises: 

b1) generating a random number at said first 
coprocessor, concatenating said random number 
with a message authentication code to produce a 
concatenated result and encrypting said concat- 
enated result with a key selected by said first 
coprocessor from said set, 
b2) transmitting a result of step b1) to said second 
coprocessor con^sponding to said antecedent in- 
formation, 

b3) receiving, from said second coprocessor a 
message and decrypting said message with a key 
from said set. if a decrypted result Includes a valid 
message authentication code, proceeding to a -step 



bS). otherwise. 

b4) repeating step b3) with each second key in 
said set until each key in said set is used without 
producing a result as set forth in step b3). and 
5 thereafter proceeding to said step d), 

b5) creating a session key by concatenating said 
random number with the decrypted result of step 
b3) exclusive of the message autiientication code 
of step b3), 

10 b6) thereafter using said session key as the spe- 
cific key. 

whereby only if said second coprocessor Is a trust- 
ed recipient will an encrypted software key be 
transmitted and only the second coprocessor with 
75 access to said session key can decrypt said entity 
to secure access to said software key. 

12. A metiiod as recited in claim 11 In which 
said metiiod includes the fbltowing steps perfomned 
at said second coprocessor If said second 

20 coprocessor is a trusted recipient 

bla) generating a second random numt>er and 
selecting a key from said set, 
b2a) concatenating said second random number of 
step bla) and a message autiientication code to 

25 produce a concatenated result 

bSa) encrypting said concatenated result of step 
b2a) to produce said message and transmitting 
said message to said first coprocessor. 

13. A metiiod as recited In claim 12 in which 
30 said second coprocessor 

b4a) decrypts information transmitted by said first 
coprocessor with a key from said set, 
bSa) if a decrypted result includes a valid message 
authenication code, retaining said decrypted result 
35 exclusive of the key of step t>4a). 

b6a) combining said retained result of step b5a) 
witii said second random numt)er to produce said 
session key, 

whereby both said first coprocessor and said sec- 
40 ond coprocessor have access to said session key 
without said session key being accessible to any 
otiier agency even if all infonnation exchanged by 
said coprocessors is observed and copied. 

14. A method as recited in one of the claims 
45 10-13 wherein the encrypted entity is a software 

key and which comprises, fbr transfening the right 
to execute, tiie furtiier steps of: 

e) acknowledging, to said first coprocessor, receipt 
by said second coprocessor of said encrypted soft- 

so ware key, 

f) deleting said software key from said first 
coprocessor and transmitting an indication of said 
deletion to said second coprocessor, and 

g) In response to said indication of said deletion 
55 transfening said software key to a permanent • 

memory of said second coprocessor. 
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15. A method as recited in claim 14 In which 
said first coprocessor stores said software key in 
permanent memory along with an indication as to 
the existence of any l)acl<up rights and in which 
said step c) includes the further steps of. 

c1) checl<ing for existence of an indication of any 

baclcup. in the presence of such indication, 

c2) invalidating such badkup, 

c3) verifying such invalidation and only thereafter, 

c4) encrypting and transmitting said encrypted 

software key. 

16. The method of one of the claims 10 - 13, 
wherein the encrypted entity is a backup and which 
comprises, to install the right to execute on a 
further processor, tiie steps of: 

e) accessing, decrypting and storing in permanent 
memory of said further coprocessor said software 
key representing a right to execute said protected 
application by a user of said furtiier coprocessor, 
and 

f) conditioning said right to execute for use only 
within a grace period. 

17. The method as claimed in any of the 
claims 1-16 which, to encrypt software keys, 
includes the steps of: 

a) accepting a software key for encryption. 

b) padding said software key with a number of a 
given length, said number including at least a com- 
ponent which is random, 

c) encrypting a result produced by said step 

d) under said first key. 

whereby said random number padding produces 
an encrypted result in response to a first encryp- 
tion operation which Is different from an encryption 
result produced on a second encryption operation 
even though an identical software key is presented 
on each occasion tiius foiling a plain text attack on 
said first key. 

18. A method of safely transferring a right to 
execute from a logically secure source coprocessor 
associated witii a host source processor to a logi- 
cally secure sink coprocessor associated witii a 
host sink processor, where said source coproces- 
sor stores at least a source key and a software key 
representing said right to execute a particular ap- 
plication and said sink coprocessor stores a sink 
key, both said source and sink keys includes within 
a set of keys stored in both said source and sink 
coprocessors, said host processors having access 
to said particular application encrypted under said 
software key, said method comprising the steps of: 

a) generating a random number at said source 
coprocessor, concatenating said random numt)er 
with a first message autiientication code to produce 
a concatenated result and encrypting said concat- 
enated result under said source key to produce a 
source identifier. 

b) generating a random number at said sink 



coprocessor, concatenating said random number 
with a second message authentication code to pro- 
duce a concatenated result and encrypting said 
concatenated result under said sink key to produce 
5 a sink identifier. 

c) transmitting said source and sink identifiers to 
said sink and source coprocessors, respectively. 

d) verifying, at said coprocessors that said identifi- 
ers were generated by companion coprocessors by 

10 1) decrypting said identifiers with keys selected 
from said set until a decrypted result includes a 
valid message authentication code as a portion, or 

2) until all keys in said set are employed without . 
any decryption result including a valid message 

f5 authentication. 

3) terminating said method If step d2) is reached, 
and otherwise, 

e) creating a session key at each coprocessor from 
said source and sink identifiers, 

20 f) encrypting said software key at said source 
coprocessors under said session key to produce a 
transmittable software key and deleting said soft- 
ware key from sard source coprocessor, 

g) transmitting said transmittable software key from 
25 said source to said sink coprocessor, 

h) decrypting, said transmittable software key at 
said sink coprocessor with ssdd session key to 
recreate said software key. and 

i) storing said software key In a non-volatile mem- 
30 ory of said link coprocessor. 

j) erasing said software key from a non-voiatile 
memory of said sink coprocessor, 
whereby said software key has been extracted and 
transfenred from source to sink coprocessors with- 
35 out exposing said software key outside said 
coprocessor and without revealing, outside ertiier 
coprocessor either of said source or sink keys. 
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@ A software asset protection mechanism segre- 
gates the right to execute software from the software 
itself. The rights to execute, when installed on a 
composite computing system. (10.20) are stored in a 
coprocessor element (20) of the composite comput- 
ing system. The software asset protection mecha- 
nism Is enhanced as described herein by providing 
for the manipulation of those rights to execute. More 
particulariy. the rights to execute can be conditioned 
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at least In terms of a valid period of execution or a 
valid number of executions. The rights to execute 
can be safely transferred from one coprocessor to 
another, or can be returned to the software vendor. 
Rnally. a method of backing up the rights to execute 
to provide the user with the rights to execute in case 
the coprocessor element of the composite comput- 
ing system fails. 
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